Rename Github repo to conform to module naming convention

[reidmv]

Describe the Bug

Repositories for Puppet modules in the puppetlabs github organization are by convention given names of the form "puppetlabs-<name>". This module repo is https://github.com/puppetlabs/provision. This does not adhere to the convention. To adhere to the convention, the repository should be renamed to https://github.com/puppetlabs/puppetlabs-provision.

I am assuming that the benefit of having and maintaining consistent organization conventions is self-evident, but if you really need me to I can come back and write something out. Let me know. 🙂

[github-actions]

This issue has been marked as stale because it has been open for a while and has had no recent activity. If this issue is still important to you please drop a comment below and we will add this to our backlog to complete. Otherwise, it will be closed in 7 days.

[reidmv]

@puppetlabs/modules this is still relevant. Please review.

[chelnak]

Hey @reidmv!

We were actually going to reach out to you internally about this. I think that this repo was purposefully named like this. I think @david22swan will have a bit more context on the initial decision.

However I'm not opposed to renaming it. Hopefully such a change would not unsettle consumers of this tool.

[github-actions]

This issue has been marked as stale because it has been open for a while and has had no recent activity. If this issue is still important to you please drop a comment below and we will add this to our backlog to complete. Otherwise, it will be closed in 7 days.

[bastelfreak]

I think this bot is a bas idea ¯_(ツ)_/¯

[david22swan]

The naming convention has historically not been used for the various devx tools that we create and maintain, only for the actual Puppet modules.

[reidmv]

I originally filed this ticket because to the best of my knowledge, the way this particular module content is referenced and used is as a module. That is, it is listed alongside all other dependency modules in .fixtures.yml files, and its content is consumed in wrapper plans as module-supplied content, e.g. run_task('provision::abs', ...).

For this particular repo, the non-conformant repo name seems to introduce more confusion than it alleviates.

If there is a concern over designating a level of support or expected use of the tool relative to e.g. supported, unsupported but high demand, unsupported but low demand, internal-use-only, etc., I believe the current initiative is to handle that not by non-conformant repo names, but by labeling. See this doc.

@david22swan curious, what distinguishes "actual Puppet modules" from "various devx tools that we create and maintain"? I don't think that distinction is self-evident here, at least not for me.

[chelnak]

Hey @reidmv , I think for me the difference here would be a Puppet module would be something managed by Puppet server & deployed to agent machines (e.g. puppetlabs-docker)..

But this is a tool that would be consumed in the process of developing new content.. we actually use it as an extension for litmus for acceptance testing.

However I do see your point, this is a module of bolt tasks which is still packaged and distributed like a Puppet module.

I'm actually more than happy to rename the repository providing it doesn't break any tooling (something that we can investigate) and am all for the new labeling system!

I've raised it again with the team and will come back around to this soon.

Thanks!

[david22swan]

@reidmv Sorry if I wasn't clear, when I said actual Puppet modules I was not referring to modules written by Puppet, but modules that are written in Puppet code and that are used by either the agent or bolt to make changes to your system.
Looking back, I realize I could have phrased it better.

[github-actions]

Hello! 👋

This issue has been open for a while and has had no recent activity. We've labelled it with attention-needed so that we can get a clear view of which issues need our attention.

If you are waiting on a response from us we will try and address your comments on a future Community Day.

Alternatively, if it is no longer relevant to you please close the issue with a comment.