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.

[davidsandilands]

So i guess my first question what would the cost be of renaming?

Is this ever deployed as a module from forge? Which I think is where the naming has its core value

[LukasAud]

After a short discussion on this topic, we have agreed that renaming the tool does not have enough positive value to outweigh the workload/potential negatives of the change.

To summarise it, the renaming process is fairly lengthy and complicated due to the tools usage in development environments. A change like this would mean a backwards-incompatible update that would require us to backtrack through all modules/tools that use it to update, potentially breaking many things in the process. In addition, provision is not deployed in the Forge, so the rename is likely to not have as much of an impact, outside of sticking to our internal conventions.

As such, we believe its not worth following up with this change.

[bastelfreak]

A change like this would mean a backwards-incompatible update

do you have concrete examples? you just need to rename the git repo. That's it.

[davidsandilands]

That makes sense to me happy from a product point of view for this to close

[LukasAud]

@bastelfreak A change in the name would most definitely mean the breaking of internal pointers in our modules. If those are not properly updated, it would end up breaking functionality. For example, pointers like this in the firewall module. Also, anyone bringing in provision in their own .fixtures.yml would face issues if he doesn't know about the change.

To put it simply, we don't think its worth the effort (renaming, adjusting pointers, investigating potential side effects or bugs) for a simple name change. And we would like to avoid breaking things outside of our control as well (there could be private repos consuming it directly from Github, since it's not on the Forge).

[bastelfreak]

You don't have to update them! Github creates automatic redirects.

[davidsandilands]

@bastelfreak good point but do you feel there's any value in the renaming for an internal tool?

[bastelfreak]

It's a public repo and customers see it. And the naming is inconsistent. And it's used by your other public tools. It's just very confusing for your customers and I don't see a reason why this module should not follow the naming convention.

[h0tw1r3]

While I agree with @bastelfreak that it should be renamed, because it is a puppet module. The fact is it has a hard requirement on the puppet_litmus gem. So, as an installable module (eg. bolt-project.yaml), it's a broken user experience.

For the record, this would be a quite useful as an installable module if that dependency could be removed (which it should).

bolt module add puppetlabs/provision
bolt task run provision::docker_exp platform=ubuntu:22.04