I’m looking for direction and discussion on implementing OpenVox as a replacement to OpenSource puppet within the Foreman ecosystem
I’d like to look at the plans and options for the 2 major use cases, and they can be addressed seperatly
Puppet Agent
Puppet Server
Puppet Agent
With Enterprise Linux 10 being released OpenSource puppet having frozen it’s public repos at Enterprise Linux 9, this now means Enterprise Linux 10 builds cannot complete with a puppet based foreman build as per foreman 3.15
There are options to make this work, some I’ve got working but how will Foreman decide to resolve this and support either a move to OpenVox, or the dual support of the new Opensource puppet layout and requirement ?
Considerations I’ve had when working this through in my local environment
global variables currently set the puppet repos and the puppet version
The puppet provider is not explicitly set anywhere (although this could be done with the repo definition)
all the provisioning templates currently reference puppet package names explicitly
provisioning templates have logic in tied to puppet names/values/facts
documentation references opensource puppet
supporting puppet modules (such as foreman-puppet) only reference puppet
support for dual running nodes aligned to foreman (Katello/Satellite) where for a period of time nodes maybe running > EL10 nodes, with both open source puppet and openvox but maybe running EL10 nodes with Openvox
Puppet Server
This is much simpler, but appears to be much more work, especially when considering not breaking existing running instances
Changes to the installer to install openvox in place of open source puppet
documentation changes - updating to openvox, plus there are some old references such as the example NTP module which doesn’t work on most modern clients this would be a good time to revisit this on the server install and setup documentation
dual running as with the agent
dual running from the installer, some nodes you may want to keep on open source puppet for a period of time while some you’ll want to use openvox, so the ability to set puppet provider as the installer seems essential
testing - what additional testing will be needed to validate releases
Initial discussions kicked off during the puppet/perforce direction issues which where very encouraging, however with EL10 landing, this is now time limited as to the best of my knowledge there is no way to integrate openvox into foreman provisioning without forking all templates and customising them
The goal based on my knowledge to have Foreman as the optional default UI for Openvox. I think we will see updates on Foreman Birthday Event and Voxconf.
I’m aware of some of the ongoing work, however there should be some sort of clarification and direction discussed or communicated so that people know what they are working towards or if they are wasting their time
This has been on my mind, but I haven’t found the time to work on this.
At this point I think we should follow Vox Pupuli’s direction (see An Unsupportable Path) and only support OpenVox. That means we can do a major version bump of the Puppet module where it will start to default to OpenVox package names and rely on users to override them if they want to go to the unsupported path of using Perforce Puppet.
Obviously we’ll want to make the upgrade smooth and that requires some testing. We’ll also need to update our CI in various places.
that’s a really good link I’d not seen, I was following the facter discussions on other mediums, to see it spelt out clearly, as you say makes it impossible to invest in puppet as a platform for foreman and it should move to OpenVox, I do see and agree with the logic behind that.
I can see how that ties into some of the work in the PR’s that Dirk linked to.
It would be great to see the actions/dependencies noted somewhere so that we know what we are working on and can contribute to (or ignore)
This for me is a good example of why a basic page/post/mailing list post is needed, what’s the plan to support it and when, RHEL being released in the middle of this change has made the provisioning of EL10 a breaking change, through just bad timing
Foreman is still an open source project where we want to encourage users to contribute the changes. That can actively steer the project. I think you bring up a lot of good points @ikonia and I’d welcome more contributions in this area. Especially on the provisioning templates. The puppet ones we have and various parameters can really use an update.
I wanted to hold off on seeing where the Perforce and Vox Pupuli collaboration would go. My expectation was where we ended up, but if we started there then that would have closed the door for sure. It may not be good and we’re a bit behind, but we’ll get there.
I think you’re highlighting the point I was trying to make @ekohl that it’s opensource and people want to contribute (myself included) but without either being able to see the direction of travel or understand how to get access or effectively contribute to that direction of travel,
I’ve asked in the development channel on the direction of travel and been told ‘hold off there is an RFC coming’ I’ve followed up on ‘where is the RFC, I’ve done some local dev work and want to know where to focus my effort’ and got no response, I’ve checked the mailing discussions and not seen a clear directional discussion, I’ve done work, only to find someone else has also done the same work and submitted an MR the day before I finished (and they did it much better) but that was duplicate effort because to my knowledge I had no idea anyone else was working on the problem, I don’t see issues raised in git or redmine (and honestly I’m not even sure of the correct place where issues should be raised now, as the pipelines check for a redmine issue, but the activity seems to be focussed on git issues)
I’m more than happy to put my hands up and take responsibility for not knowing the right way to approach this or engage with this, but it’s certainly not from a lack of trying or effort, and this seemed both a basic requirement ‘puppet will break after his date’ so clear discussion / priority etc would really been valuable to me.
I’m more than happy to pick up work such as the templates, but I need to know or be able to discuss requirement or direction, eg: is it ok to just drop support fully for opensource puppet knowing that EL10 onwards means it’s over, do we want to have parameter driven templates to support options, in which case we’ll need to do more changes to support the new open source puppet repos as an installation source, can we clear out the open puppet repos packages (doubtful because of the satellite compatibility requirement to include RHEL 7 - maybe even 6 ? etc.
I guess it’s a question of how to get the information or how to constructively engage to build the info, I’d hate to go off and do a chunk of template work to then be told ‘oh we are just dropping all reference to opensource puppet’ or the opposite ‘no no, you’ve got to keep existing support because Satellite will require it for X years’ etc or duplicate work that’s ongoing with other people as I’ve not really seen it until an MR landed.
