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

No longer possible to install this role standalone using ansible-galaxy #64

Open
mhuxtable opened this issue Apr 21, 2019 · 3 comments
Open

Comments

@mhuxtable
Copy link
Contributor

It was formerly possible to install this role standalone using the command ansible-galaxy install debops.sshd. Upon so doing now, the main debops role is downloaded to the roles directory under the name debops.sshd, which provides the false illusion that the role has been properly downloaded and is ready for use.

This is a rather inconvenient turn of events which seems to be impacting other roles in the debops collection too. It means the README in the root of the repo is, sadly, wrong. It also makes use of these roles in standalone environments much harder as the standard Ansible tooling cannot be used to obtain them.

I'm not sure if this is an upstream change at Ansible Galaxy, and I have not investigated the packaging process used by these roles in enough detail to determine what, if anything, might be a good next step.

@drybjed
Copy link
Member

drybjed commented Apr 21, 2019

The old standalone DebOps repositories have been removed from Ansible Galaxy, because they are no longer actively maintained. The project development has been moved to the DebOps monorepo which is also published on the Ansible Galaxy. Unfortunately, the ansible-galaxy tool does not understand the multi-role format supported by Galaxy, but the newer mazer tool does and it can be used to install the DebOps roles correctly.

Check the DebOps installation instructions via Ansible Galaxy for more details.

@mhuxtable
Copy link
Contributor Author

Thanks.

The practicalities of the large number of repos notwithstanding, does it make sense to:

  • add a note to that effect to the README of these standalone repos, and/or
  • mark these repos as archived in GitHub

as an indication that these standalone repos might not be what the user expected?

@drybjed
Copy link
Member

drybjed commented Apr 26, 2019

Yes, some of the old repositories have already been archived, I want to deal with the issues/pull requests in the rest of them before archiving. I suppose that adding an information about the migration to the repository description might be a good idea as well.

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

No branches or pull requests

2 participants