Add Zeitwerk loader support

[ofedoren]

Not sure what's the right branch for opening PRs against :/

Not mergeable until deps are merged.

[ofedoren]

Requires 4 plugins: tasks, rex, ansible, katello, I suggest revisiting this plugin after the deps are merged.

Not quire ready, probably some additional changes will be made.

[ekohl]

We'll need to drop the temporary bits.

[ofedoren]

Since it's green now, should I remove the last commit? Or leave it for you to decide when there is more appropriate timing?

[evgeni]

I'd remove it, but I am also not the maintainer of this plugin :)

[jeremylenz]

@ofedoren is this ready for merge?

[ekohl]

This has a similar issue as what theforeman/foreman_virt_who_configure#201 shows. Right now it's only testing with a released version of Katello, but that doesn't contain the Zeitwerk changes. Previously it added a gemfile.d file to use a git version, but now CI is red. If you add that change, katello-devel breaks.

Edit: I'm also entirely unsure how this repo does branching. The default is a v10 branch and there is no concept of master/develop so does that mean it first needs to change the default branch to v11 since it's breaking? That's why I'm not merging this now.

[chris1984]

This has a similar issue as what theforeman/foreman_virt_who_configure#201 shows. Right now it's only testing with a released version of Katello, but that doesn't contain the Zeitwerk changes. Previously it added a gemfile.d file to use a git version, but now CI is red. If you add that change, katello-devel breaks.

Edit: I'm also entirely unsure how this repo does branching. The default is a v10 branch and there is no concept of master/develop so does that mean it first needs to change the default branch to v11 since it's breaking? That's why I'm not merging this now.

@ekohl we used v10 as the branch name since we needed a new release but we were in between Foreman releases for 6.16

Talking with @ShimShtein he wanted to name the next branch v17 to more match the Satellite releases downstream so we know what version of satellite to attach things to for cherry-picks etc.

We were going to make a new branch after Satellite 6.16 goes GA, but if it's blocking stuff, I can talk to Shim Thursday during our 1:1 and see if we can branch early.

[ShimShtein]

@ekohl v10 is intended to be used with Foreman 6.12 (without Zeitwerk). I see this change will cause CI failures in the upstream, so let's switch to a new branch and make sure we're off the hook.

Talking with @ShimShtein he wanted to name the next branch v17 to more match the Satellite releases downstream so we know what version of satellite to attach things to for cherry-picks etc.

I have also seen your comment about not attaching versions of plugins to downstream products (which is understandable). Any advice on better version numbering? Maybe attaching to the predicted Foreman version? Like calling the next one v13 (as it will go with Foreman 3.13)?

[jeremylenz]

Any advice on better version numbering? Maybe attaching to the predicted Foreman version? Like calling the next one v13 (as it will go with Foreman 3.13)?

Sure that sounds fine to me, but I think the more fundamental question is why does rh_cloud need to change its default branch every upstream major release? Why not just have a main or develop and then branch the same way as all other plugins?

[ShimShtein]

Why not just have a main or develop and then branch the same way as all other plugins?

Mainly historical reasons. Originally we were developing a couple of versions in parallel each version for the released and supported Satellite version. Currently it's a bit less needed, although still, having the branch name to indicate what version of the plugin is currently under development sounds like a good idea to me. As I have said to Ewoud, it's a dilemma for me now, as both approaches have their own advantages.

Specifically in the case of Zeitwerk it's good that the PR wasn't merged, since the current branch is intended to be used with Foreman 3.12 which does not have Zeitwerk.

[ehelms]

My 2 cents:

The develop branch should track with Foreman's develop branch. And if a branch is needed to track a released version of the plugin, create that branch. This is the model all the other plugins take, and we should pattern match for continuity, ease of understanding and procedure.

[ofedoren]

Hmm, 1 of 3 test:foreman_rh_cloud tasks fails for some reason...

[ofedoren]

... but now everything is green ...

[chris1984]

Thanks @ofedoren