pagure

Clone

#4804 Improvements to Vagrant VM provisioning and operation
Merged a month ago by pingou. Opened 9 months ago by sudoman.
sudoman/pagure vagrant-improvements  into  master

file modified
+2 -1 
@@ -4,7 +4,7 @@ 
 

  VAGRANTFILE_API_VERSION = "2"
 

  

  Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
 

-  config.vm.box_url = "https://download.fedoraproject.org/pub/fedora/linux/releases/30/Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-30-1.2.x86_64.vagrant-libvirt.box"
 

+  config.vm.box_url = "https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/30/Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-30-1.2.x86_64.vagrant-libvirt.box"
 

   config.vm.box = "f30-cloud-libvirt"
 

  

  
@@ -27,6 +27,7 @@ 
 

   # config.vm.synced_folder ".", "/vagrant", type: "nfs", nfs_version: 4, nfs_udp: false
 

   config.vm.synced_folder ".", "/vagrant", disabled: true
 

   config.vm.synced_folder ".", "/srv/pagure",
 

+      ssh_opts_append: "-o IdentitiesOnly=yes",
 

       type: "sshfs"
 

  

   # To cache update packages (which is helpful if frequently doing `vagrant destroy && vagrant up`)

These commits fix a few of the issues I ran into while trying to get the Vagrant based deployment up and running. There is more work to do, but once the Vagrant based installation is working, it should lower the bar to contributing to Pagure.

Can we raise this to 4096 instead? That gives us a bit more wiggle room...

That is an option, but I'm concerned about users who may not have much RAM on their computers. At 3 GB total RAM, that leaves an additional 1 GB for Pagure to make use of after it's already running.

Hmm, that's fair.

:thumbsup:

Now that I think of it, I'm not sure if restarting services every 5 seconds upon failure is necessarily a great idea. If a developer patches Pagure, and a service consistently crashes right away, it will get restarted rather frequently.

This could produce a lot of debug output. I'm not sure if frequently restarting would also break how other services interact with the one that may only work for a few seconds at a time.

I think that in most cases this kind of behavior would be fine. However there could be some edge cases. Since the Vagrant based deployment is geared towards dev environments, that may be less of a concern, and more of an annoyance. In any case, without this change, or another solution, the Vagrant deployment isn't working yet.

Now that I think of it, I'm not sure if restarting services every 5 seconds upon failure is necessarily a great idea. If a developer patches Pagure, and a service consistently crashes right away, it will get restarted rather frequently.

I'm wondering a bit about this as well, I fear that 5seconds may not be enough for a developer to find which service did not behave as expected and the longer they take to figure which service crashed the longer they may end up needing to scroll up to find the traceback.

@sudoman I read the other day on irc that you had problems to run systemctl --user using su...

that's because the vagrant user is not linger enabled. systemctl users session is launched after user's first login by default. If you enable lingering for that user it will start on boot.

a task on the provisioning ansible that runs loginctl linger-enable vagrantas root should fix that and allow you to use systemct --user from a su session.
Edited 9 months ago by jlanda

@sudoman with the recent changes we've made to the vagrant box, do we still need these? If so, could you rebase? It seems it conflicts now :)

@sudoman ping?

Sorry about the dropped ping. The only part that may be useful still is the following:

https://pagure.io/fork/sudoman/pagure/c/b7cb024a8bec696287b1313c9e35eeaaa8602926

That should resolve an issue with running 'vagrant up' after adding one's SSH key to the Pagure user dashboard. I'll investigate and create a new PR.

@sudoman :thumbsup: for me, just drop the other commit from your branch and force push and it'll update this PR

@sudoman did you see my last comment?

rebased onto 78a62ed
a month ago

Hi @pingou, sorry for the delay. I force-pushed that one change and another patch to correct the URL for the Fedora 30 Vagrant image.

:thumbsup:

I'll merge this and look at rebasing the vagrant image to something newer in a different PR :)

Pull-Request has been merged by pingou
a month ago
Changes Summary 1
+2 -1
file changed
dev/Vagrantfile.example
Powered by Pagure 5.12.1
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.