Thanks for the reply.
To clarify/summarize here are some thoughts and problems:
Yes, I know the the galaxy client supports using other git backend systems
via the git protocol. We are currently doing this, but I will like to avoid
it. Each time we reference a git repo with the ansible galaxy we need to
find a way to get a credential to the server fetching the roles so that it
can be downloaded by the ansible-galaxy command. (Obviously we can use
public repos but that isn't the point)
Another major reason why I would like the galaxy server to host different
git backed systems is so that it discovery of roles, and dependancy
management of roles (where roles depend on other roles) can be quite
completed to manage without something like Ansible Galaxy Server
understanding meta.yml and composing these dependancies for you.
Another big reason this is useful, is it helps us have a registry of roles,
this makes our development faster as we can don't have to repeat ourselves,
if we can easily discover roles that have been created by other teams (the
whole point of Ansible Galaxy). This registry is important for me, as I
would like to use it to make self service systems easier to make, as the
user can pick and chose roles that have been created, and deploy these to a
In respect of your comment before. Yes, I agree it will be an invasive
change. I think it its sill useful in the downstream Galaxy. This is
because some companies may have their git systems public, and may want to
use the public ansible galaxy system, and not have to maintain a mirror in
I was thinking (again, I'm not super good at architecting a solution like
this) that if the ImportRoles task was an interface , and we implement each
type of git backend system (GithubImportRoles, BitbucketImportRoles,
GitlabImportRoles, etc etc) then we can interface this. The problem might
be with migration of data from old to new due to model/db changes.
Yes, the naming super confusing. As mentioned, here:
On Sat, Oct 15, 2016 at 4:47 AM Greg DeKoenigsberg <g...@ansible.com> wrote:
> This is one of the issues of overloading the name "Galaxy".
> Galaxy is two things, a server and a client.
> The Galaxy server is a mechanism for indexing roles, and making them
> available to the Galaxy client. Github isn't great at providing
> searchability and metadata for content. Galaxy isn't great either, but it's
> improving. :)
> The Galaxy Client downloads from the Galaxy server by default, but can be
> set to download from any Git repo. This isn't always clear to users, so we
> need to do a better job of surfacing this capability.
> On Fri, Oct 14, 2016 at 11:27 AM, Ricardo Carrillo Cruz <
> ricardo.carrillo.c...@gmail.com> wrote:
> I see, that makes sense, thanks.
> 2016-10-14 17:26 GMT+02:00 Brian Coca <bc...@ansible.com>:
> @Ricardo, on the galaxy.ansible.com (galaxy-server) side, it only allows
> importing roles from github.com as well as requires github.com accounts.
> I believe they want to extend the server software to allow for other
> 'origins' both for accounts and for shared roles.
> Brian Coca
> You received this message because you are subscribed to the Google Groups
> "Ansible Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ansible-devel+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> Greg DeKoenigsberg
> Ansible Community Guy
You received this message because you are subscribed to the Google Groups
"Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.