Video with the updated information on how to deploy the dev environment

[waldirio]

youtube video link updated, video with the updated information on how to deploy the dev environment

[waldirio]

Hello,

Just to keep on track, I tested with a local implementation, and the change is working as expected.

Thank you!
Waldirio

[ekohl]

Thank you for taking the time to work on this. I briefly skimmed through the video and have some questions.

You install using the official packages and then the plugin system, but we only document using packaged versions on https://theforeman.github.io/forklift/vagrant/#centos-stream-8-9. That's also what we use in our CI pipelines. The latest official packages have a non-free license that I'd like to avoid. They also have officially packaged vagrant-libvirt so your host doesn't need any devel dependencies installed.

I'm also not a fan of the hostmanager plugin (& friends). I have a version like https://liquidat.wordpress.com/2017/03/03/howto-automated-dns-resolution-for-kvmlibvirt-guests-with-a-local-domain/ (based on Dominic's https://m0dlx.com/blog/Automatic_DNS_updates_from_libvirt_guests.html). In addition to that I have set up a hook to reconfigure systemd-resolved on my host so I can use real DNS to talk to ever host. Death to /etc/hosts if you ask me.

Then for SSH you have a very complex command, but wouldn't it be easier to recommend using vagrant ssh-config $box and then copy that into their ~/.ssh/config with additional forwards if needed?

Also, https://developer.hashicorp.com/vagrant/docs/networking/forwarded_ports is how Vagrant natively supports forwards. In fact, we already have some forwarding logic in forklift: https://github.com/theforeman/forklift/blob/4019844c56717898b0c3cf12cc1c3e2eb3d98056/vagrant/lib/forklift/box_distributor.rb#L287-L295. I don't use this myself since I have no need for forwards so I don't have a strong preference, but you now talk a good 5 minutes about something that I think can be a lot simpler.

Since I don't use any forwarding, I don't have a need to disable the firewall. It just works out of the box for me. I think we should stress that the forwarded use case isn't needed for everyone.

Organization wise you set up the libvirt user very late. I'd do that as part of the libvirt setup itself.

Near the end you change the hostname, but already mention the caveat that you shouldn't upload it. That's because you're not using the mechanisms we already have. You can see it already reads the settings. This means you can set these values in config/settings.yaml. Conveniently, this file is already excluded from git.

[waldirio]

Thank you for taking the time to work on this. I briefly skimmed through the video and have some questions.

You install using the official packages and then the plugin system, but we only document using packaged versions on https://theforeman.github.io/forklift/vagrant/#centos-stream-8-9. That's also what we use in our CI pipelines. The latest official packages have a non-free license that I'd like to avoid. They also have officially packaged vagrant-libvirt so your host doesn't need any devel dependencies installed.

I'm also not a fan of the hostmanager plugin (& friends). I have a version like https://liquidat.wordpress.com/2017/03/03/howto-automated-dns-resolution-for-kvmlibvirt-guests-with-a-local-domain/ (based on Dominic's https://m0dlx.com/blog/Automatic_DNS_updates_from_libvirt_guests.html). In addition to that I have set up a hook to reconfigure systemd-resolved on my host so I can use real DNS to talk to ever host. Death to /etc/hosts if you ask me.

Then for SSH you have a very complex command, but wouldn't it be easier to recommend using vagrant ssh-config $box and then copy that into their ~/.ssh/config with additional forwards if needed?

Also, https://developer.hashicorp.com/vagrant/docs/networking/forwarded_ports is how Vagrant natively supports forwards. In fact, we already have some forwarding logic in forklift: https://github.com/theforeman/forklift/blob/4019844c56717898b0c3cf12cc1c3e2eb3d98056/vagrant/lib/forklift/box_distributor.rb#L287-L295. I don't use this myself since I have no need for forwards so I don't have a strong preference, but you now talk a good 5 minutes about something that I think can be a lot simpler.

Since I don't use any forwarding, I don't have a need to disable the firewall. It just works out of the box for me. I think we should stress that the forwarded use case isn't needed for everyone.

Organization wise you set up the libvirt user very late. I'd do that as part of the libvirt setup itself.

Near the end you change the hostname, but already mention the caveat that you shouldn't upload it. That's because you're not using the mechanisms we already have. You can see it already reads the settings. This means you can set these values in config/settings.yaml. Conveniently, this file is already excluded from git.

Hello @ekohl

You are very welcome and thank you for all your feedback/points. As you said, once you are using it on your local machine, it would be much simpler, I totally agree. In my case, I have a mac (I'm doing some tests on it), and unfortunately, virtualization is not a thing here. With that said, an external box to develop it's my next step.

Checking with diff developers, there is no standard, and my goal was indeed to make this process simple and easy to follow/deploy.

Checking the previous video, the version is outdated, and some steps are not functional anymore.

About the plugins that manage the entry on /etc/hosts, I agree, that there are different ways to achieve the same goal, my motto here is to keep it simple, once this plugin does everything we need, with no additional setup/cost/energy, I see it as a great option.

Finally, yes, vagrant ssh xyz would be a great option, assuming I'm running on my server, and I would like to access it remotely, so, once again, in order to keep it simple .., I'm moving this way.

Again, I spoke to diff eng who are working on this platform daily, there is no standard, and most of them do it in a different way (ssl tunel, socks access via web browser, ...), the main goal here is to keep it simple, and easy, for someone who would like to start just today.

I can tell you, based on my own experience, when I tried to follow the docs, to spin up this env, it was painful, some missing info, and a lot of diff docs to check .., maybe, for the team/professional who are working with this project for a while, this is on the bloodstream, but for the new ones, it's not.

I hope this covers some of your points, and I'm totally open to any change/recommendation that you would like to share (you did some already :-) ).

I'll wait for your response.

Thank you!
Waldirio

[ekohl]

Finally, yes, vagrant ssh xyz would be a great option, assuming I'm running on my server, and I would like to access it remotely, so, once again, in order to keep it simple .., I'm moving this way.

Note I said vagrant ssh-config, not vagrant ssh. The former prints out the entry for your ~/.ssh/config so you can use ssh instead of vagrant ssh (like you did). Then if you add LocalForward options there you don't need to remember a huge SSH command but you can give a nice and easy name.

[waldirio]

Finally, yes, vagrant ssh xyz would be a great option, assuming I'm running on my server, and I would like to access it remotely, so, once again, in order to keep it simple .., I'm moving this way.

Note I said vagrant ssh-config, not vagrant ssh. The former prints out the entry for your ~/.ssh/config so you can use ssh instead of vagrant ssh (like you did). Then if you add LocalForward options there you don't need to remember a huge SSH command but you can give a nice and easy name.

Hello @ekohl

Interesting, and indeed, this is another way, thank you for that!

Definitely, I'll try it out.

[ekohl]

Maybe another thought: does it make sense to create a video to set up forklift. Then another video that assumes you have forklift set up to create a development environment. That might make it easier to update parts of it

[waldirio]

Hello @ekohl

Thank you again for your input. If you believe it's valid, that's ok, and I'm totally open if someone else would like to create it, I mean, in small pieces, and please, don't misunderstand me here.

At this moment, I have a long list of videos of Red Hat Satellite to do, some of them already recorded and ready for production, and 13+ videos, only for provisioning .., which will be great, and also, that will consume a lot of time, as you may know.

For the upstream, I recorded this one, a lot of small ones that are related to plugins, each video covering each plugin, and one that will be released soon about foreman and foreman + katello deployment, for those who are interested in play with the project.

Split something that is already done, it's not in my plan at this moment, and again, if there is someone else interested in splitting this down, I'll be more than happy with that.

Please, let me know what you think, and if you believe this is not good content to be on this page at this moment, I'll totally understand.

Thank you!
Waldirio

[ekohl]

I'm mostly thinking out loud now and appreciate you treating it that way. Next week I'll take a look with fresh eyes