Skip to content
This repository has been archived by the owner on Jan 10, 2023. It is now read-only.

PDK Conversion Guide #1

Open
9 of 14 tasks
logicminds opened this issue Apr 8, 2020 · 6 comments
Open
9 of 14 tasks

PDK Conversion Guide #1

logicminds opened this issue Apr 8, 2020 · 6 comments

Comments

@logicminds
Copy link
Collaborator

logicminds commented Apr 8, 2020

PDK Templates conversion guide

This document serves as the steps required to convert voxpupuli organization to start using the pdk on current and future puppet nodules.
Please note this is an opt-in strategy as to not cause disruption with existing modules.

Step 1 (Pdk-templates):

  • Fork the pdk-templates
  • Create branch from pdk-templates/1.17 and name vp-1.17 (all future branches will follow this same naming scheme)
  • Copy and/or sync files from modulesync templates over to pdk-templates fork
  • Commit changes
  • Push changes
  • Update travis file to work with VoxPupuli standards
  • Update Gemfile to work with VoxPupuli acceptance tests, and litmus
  • Perform test run of publishing Gem
  • Have peers review pdk-templates are similar to modulesync_config templates

Future pdk-template updates will follow this workflow:

  1. Fetch the changes from puppetlabs/pdk-templates
  2. Create branch from pdk-templates/X.XX and name vp-X.XX
  3. Rebase the last named branch ie. vp-1.17 into this new branch
  4. push changes

This gives us the ability to add in our own changes, as we will likely have different opinions on which files are included in the templates by default.

Step 2: (PDKSync )

  • Create a new repo named pdksync_config
  • In the gemfile reference either the pdksync gem or the github repo
  • Create and initial pdksync.yml file, similar to how modulesync works
  • Reference the pdk-templates version we will to sync all modules too
  • Create a CI file that allows us to either constantly run pdksync or through a push button model

Step 3: Convert or Create modules with PDK at will

Since this can be done in a number of ways I have outlined all the possibilities and provided a workflow for each method

Existing Puppet Module Conversion Workflow using pdksync

  1. Remove module from modulesync configs
  2. Add module to pdksync managed_modules.yml
  3. Commit changes and CI should run through managed_modules.yml and update to use latest templates

PDK Puppet Module Conversion Workflow using pdk

  1. Remove module from modulesync configs
  2. Use pdk convert and pdk update to convert the module to pdk using either puppet or voxpupuli templates
  3. Follow New puppet module workflow

New Puppet Module Workflow using pdk

  1. New modules can be created with PDK either referencing the puppetlabs or voxpupuli pdk-templates
  2. New module will be added to pdksync managed_modules list
  3. Pdksync runs pdk update on this new module using the voxpupuli fork of pdk-templates

Notes

  • The pdk version will always have a version associated with it in the pdk-templates repo.
  • The VoxPupuli fork will pull in the latest changes to pdk-templates and merge in additional changes thereafter if required.
  • Using PDK for a module is opt-in only
  • Users cannot use modulesync and PDK
  • PDKsync gem will perform the necessary automation to keep a module updated, however the content of those changes comes from pdk-templates fork.
  • There is the fundamental difference between modulesync and pdksync. With modulesync the templates and automation are stored as a single repo. Where with pdksync the templates are separated. This separation allows pdk CLI and pdksync to utilize the same template repos and have a single source of truth.
  • PDKsync can allow a module to decide on a specific version of the pdk-templates if desired
  • PDKsync can force a specific version of pdk-templates on the module if desired.
  • A module cannot be in modulesync list and PDKSync at the same time, chaos will ensue.
  • PDK and PDKsync both use pdk update to make the changes.

https://github.com/puppetlabs/pdk-templates
https://github.com/puppetlabs/pdksync

@ekohl
Copy link
Member

ekohl commented Apr 9, 2020

I think this repository shouldn't be named the same as https://github.com/puppetlabs/pdksync because that's confusing. Should it be pdksync_config like https://github.com/voxpupuli/modulesync_config?

Edit: have you considered directories within a single repository?

@logicminds
Copy link
Collaborator Author

logicminds commented Apr 10, 2020

This is a great suggestion. I think directories will be required at some point to support some customization for grouping of some sort. For now we just have the single use case. Was there something you had in mind?

@bastelfreak
Copy link
Member

FYI: I pinged Puppet Inc (again) about gems build for Ruby 2.7: puppetlabs/puppet-module-gems#127

@logicminds
Copy link
Collaborator Author

The voxpupuli-test gem is causing issues with pdk.

Bundler could not find compatible versions for gem "rubocop":
  In Gemfile:
    puppet-module-posix-dev-r2.6 (~> 0.4) was resolved to 0.4.4, which depends on
      rubocop (~> 0.49.0)

    puppet-module-posix-dev-r2.6 (~> 0.4) was resolved to 0.4.4, which depends on
      rubocop-rspec (~> 1.16.0) was resolved to 1.16.0, which depends on
        rubocop (>= 0.49.0)

    voxpupuli-test (>= 1.0.0) was resolved to 1.1.0, which depends on
      rubocop (~> 0.49.1)

Bundler could not find compatible versions for gem "rubocop-rspec":
  In Gemfile:
    puppet-module-posix-dev-r2.6 (~> 0.4) was resolved to 0.4.4, which depends on
      rubocop-rspec (~> 1.16.0)

    voxpupuli-test (>= 1.0.0) was resolved to 1.1.0, which depends on
      rubocop-rspec (= 1.15.0)

@ekohl
Copy link
Member

ekohl commented Apr 14, 2020

I don't know why we pin to 1.15.0 specifically in voxpupuli-test but a PR there is welcome.

On a side note: I think we should avoid the puppet-module-posix-dev dependencies and use our own. With voxpupuli-test and voxpupuli-acceptance we have our own modules for this. At least for posix development, haven't looked at Windows yet.

My ideal scenario is that modulesync_config can be used as a PDK template repository. This would allow us to have the benefits on the PDK (are there any?) without the downsides of pdk-templates.

@logicminds
Copy link
Collaborator Author

I recently added a doc around managing templates: https://github.com/voxpupuli/pdk-templates/blob/vp-latest/VP_README.md

Also the puppet-format module runs on pdk already as the guinea pig.

The acceptance test stuff is missing ATM as I would need to learn how this is currently accomplished with modulesync and travis.

Here is an example travis run:
https://travis-ci.org/github/voxpupuli/puppet-format/builds/707074258

What we have is a good start but definately need some refinements from those who know the vox workflow as I don't.

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

No branches or pull requests

3 participants