Galaxy-Operator

Project Discussions
1

Is there anyone in the know that can share any news or information about the new Galaxy Operator? I’ve been seeing bits and pieces of it here and there, but the official https://github.com/ansible/galaxy-operator/ repo is set to private. I can understand it not being GA yet, but I’m curious to know if there’s a ballpark target release date.

4 Likes
2

I too would like to know if there is an ETA :smiley:

In the reply to the Issue you created, the ansible branch of Pulp Operator will be published as Galaxy Operator, but there is indeed no update:

2 Likes
3

@Denney-tech @kurokobo Thank you for the interest! We have been bootstrapping the new repo and moving to using the galaxy team maintained galaxy-ng and galaxy-ui images.

We just finished renaming the CRD from Pulp → Galaxy, which was one of the last things to get into place. We hope to make the repo public later this week, or early next week. I’d just like to get a bare bones release GHA in place so we can hit the ground running with a release for folks to try out.

@aknochow and I will post an update on this thread when it goes public.

7 Likes
4

@kurokobo @Denney-tech Here you go! Let us know what you think. :slight_smile:

GitHub - ansible/galaxy-operator: Galaxy-Operator

(Official announcement will be Monday…)

New docs page:

4 Likes
5

Sweet! I’ll be out on vacation for the weekend, but will happily look forward to the announcement on Monday.

In the meantime, the repo is still private, so I can’t follow that first link.

Edit: aaannd it’s public, yay! Lol

6

@Denney-tech Repo is public, that first link was to the release that we haven’t released yet and I just caught that. Fixed… :slight_smile:

1 Like
7

Lol, nice. Thanks for fixing your links!

1 Like
8

@aknochow will we be seeing this added to the community operator catalogs as well?

9

I just pushed one last update to the README and docs so you have some good reading for your vacation. :sunglasses:

Yes this will be available in the community catalog but I’ll defer to @rooftopcellist for more details on when that will be and he’s also heading out on some well-earned vacation.

2 Likes
10

Hi, thanks for updating and congrats for going new repo live :smiley:

May I have couple of questions:

  • Dou you have any plan to release the images that tagged by version for quay.io/ansible/galaxy-ng and quay.io/ansible/galaxy-ui? There are versioned release under pup for galaxy, galaxy-minimal, and galaxy-web.
  • This is a question from just my technical interest, but what is the reason that adopting Ansible based SDK for Galaxy Operator? I know in the past Pulp Operator used Ansible based SDK and transformed to use Go based SDK, and now back to Ansible based SDK in Galaxy Operator. I like Go based one too since it’s simply fast.
2 Likes
11

  • I too would like to have version tags published for the galaxy-ng and galaxy-ui quay.io registries, we should talk to the Galaxy team and see if they would be open to that. cc @rochacbruno

  • As for golang vs. ansible. The Ansible org never actually used the pulp-operator once it was re-written in golang. We tried to figure out a way to make it work but there were many complications.

  • The pulp team made many schema changes when they rewrote the pulp-operator in golang, which made it difficult to maintain backwards compatibility. We looking into doing a new apiVersion for the CRD, but it had it’s own complications…

  • We are an ansible shop, we decided it would be best to use an ansible operator and try to improve any performance issues we run into along the way.

  • Ansible is easier to maintain, and we are a very small team. We also maintain many operators, all of which are ansible-based. So sticking to Ansible avoids learning the nuancing of the golang operators and having to solve every problem we run into twice in two languages.

  • It is easier to onboard new engineers on an ansible-based operator rather than a go-based one, especially in an org full of engineers familiar with ansible

4 Likes
12

Thank you for providing detailed background, that make a lot of sense.

Indeed, if the team is small, it is reasonable to narrow down the tool/architecture used. Perhaps it will be easier for users to use Operator for AWX, EDA and Galaxy because they will be similar in how they use them :smiley:

I see that the latest version of Galaxy Operator was released a few hours ago, so I’ll give it a try.

2 Likes
13
2 Likes
14

I’m also in favor of matching the galaxy image tags to the galaxy-ng git release tags.

1 Like
15

Sent two PRs :smiley:

4 Likes
16

@kurokobo thanks for the search fix! I was going to figure that out next week and you beat me to it! Still working on documentation… :slightly_smiling_face:

17

Since I’m using OCP, my preferred operator installation method is through a catalog source. I will wait for this to get into community-operators/operators at main · k8s-operatorhub/community-operators (github.com) and try it out then.

Will the existing galaxy-operator in the catalog be removed from the alpha channel, or will this one just slot next to it in the beta channel?

18

@Denney-tech We do intend to publish new versions of the Galaxy Operator to OperatorHub, but we still need to set up the automation to do this.

2 Likes
19

@Denney-tech The workflow that pushing bundle and catalog images is now fixed, which is the first step towards getting this available on OperatorHub.io.

So it is not yet available via the operatorhub.io catalog image, but you could apply a new CatalogSource resource to make it available now if you want. Here is an example:

---
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: ansible-galaxy-catalog
  namespace: galaxy
spec:
  displayName: 'Ansible Galaxy Operators'
  image: "quay.io/ansible/galaxy-operator-catalog:latest"
  publisher: 'Ansible Galaxy Dev Team'
  sourceType: grpc

A moment or two after that yaml is applied, you should then have it available to be installed. You can do so by applying a subscription object:

---
apiVersion: v1
kind: Namespace
metadata:
  name: galaxy

---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: operatorgroup
  namespace: galaxy
spec:
  targetNamespaces:
    - galaxy

---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: galaxy
  namespace: galaxy
spec:
  channel: alpha
  name: galaxy-operator
  source: ansible-galaxy-catalog
  sourceNamespace: galaxy

This is rouighly the same yaml that you would be applying with the one line command from operatorhub.io if it were already published there.

That will create a galaxy operator in the galaxy namespace.

$ oc get pods
NAME                                                              READY   STATUS      RESTARTS   AGE
ansible-galaxy-catalog-g6fvs                                      1/1     Running     0          3m13s
b9c9d3127a73e1ad9bc6b2069198dec5568cda6547fcc5ae5752e35d2a7dc9g   0/1     Completed   0          56s
galaxy-operator-controller-manager-fb54598db-kwp9b                2/2     Running     0          37s

FYI, this release will be announced shortly, but this is the one you would be deploying if you do the above steps:

1 Like
20

Oooooo shiny! :smiley:

I’m definitely happy with standalone bundle/catalog images. I already have a build pipeline that consolidates select Operators into a custom catalog. It just works best when I can iterate over what ends up in the community catalog repos so the upgrade paths work.

1 Like