Re: [Arches] Docker-compose image have 404 for all static assets.
https://github.com/archesproject/arches/pull/4801 I've put my small tweak as a PR, if you wanted to check it out Vincent and test yourself! Ben On Wed, 24 Apr 2019 at 10:44, Ben O'Steen wrote: > Rob G had similar issues running the test suite, but had an extra fail as > well! Not sure what is going on but I think some tests need looking at > possibly! > > Ben > > On Wed, 24 Apr 2019 at 05:13, Vincent Meijer > wrote: > >> Nice! >> Sounds like that is a regular assertion error and independent of the >> environment, or does the test succeed locally? >> >> On Tue, Apr 23, 2019 at 6:46 PM Ben O'Steen wrote: >> >>> Good news, Bad news I'm afraid: >>> >>> Good news? the environment flag seems to have done the trick and the >>> Elasticsearch container doesn't quit after running its checks. >>> >>> Bad news? There is a failing test: >>> >>> FAIL: Test bulk deleting of documents in Elasticsearch >>> -- >>> Traceback (most recent call last): >>> File "/web_root/arches/tests/search/search_tests.py", line 66, in >>> test_bulk_delete >>> self.assertEqual(se.count(index='test'), 10) >>> AssertionError: 11 != 10 >>> >>> >>> https://cloud.docker.com/repository/registry-1.docker.io/benosteen/arches/builds/88c8a09d-9fa6-44f5-a86a-fc960ba2f327 >>> >>> >>> >>> On Tue, 23 Apr 2019 at 08:23, Ben O'Steen wrote: >>> That is an odd error, certainly works locally but not when docker hub runs the test setup. One thing it could be is that if docker hub are using default EC2 instances, they have the vm.max_map_count set too low for Elasticsearch. It is high enough that Elasticsearch will boot but not enough to stop it erroring out after a very short period. I've been using 'sudo sysctl -w vm.max_map_count=262144' on the host to avoid this which is why it is not erroring for me during Elasticsearch's bootstrap checks. We should be able to disable the checks (turn them from hard errors to soft warnings in the logs) by passing the ES container "discovery.type=single-node" as an environment variable. I'll try this on my docker hub account and see if that can fix it. Ben On Tue, 23 Apr 2019 at 03:12, Vincent Meijer wrote: > It seems there are problems with our automated docker builds, which is > presumably the cause of the 4.4.1 tag not existing. > > Latest build of the master branch failed: the Elasticsearch endpoint > cannot be reached during the unit tests. > Failed to establish a new connection: [Errno -2] Name or service not > known) > > https://cloud.docker.com/u/archesproject/repository/registry-1.docker.io/archesproject/arches/builds/ca27a312-4d02-4e1b-b65c-2f34cb22ef79 > > > Not sure why this is, as the Elasticsearch container seems to be up > and running during the test. > > Full command: run_tests > Command: run_tests > Testing if database server is up... > Database server is up > Testing if Elasticsearch is up... > Elasticsearch is up > > However, the 4.4.1 build does not seem be have been triggered at all, > and I'm at a loss as to why this hasn't happened... > Possibly someone with more permissions than me could check the webhook > settings in the Github repo? :) > > Vincent > > On Fri, Apr 19, 2019 at 12:40 AM Ben O'Steen > wrote: > >> >> - As for Docker 4.4.1 not being put onto Docker Hub, I'm not sure why >> that is. I've been making my own images of the codebase in lieu of that. >> >> - I don't get the System settings errors you mention, though I am >> using Arches based on a much more recent codebase (I created my Arches >> base >> image last week or so from the master branch). >> >> Ben >> >> On Tue, 16 Apr 2019 at 14:39, Matthias Bussonnier < >> bussonniermatth...@gmail.com> wrote: >> >>> Thanks Ben, >>> >>> That was useful, I guess I got confused between DEV mode 8000 and >>> PROD port 80, I got it to work now. >>> >>> 2 followup questions; now that I can see the website and login: >>> - I see on dockerhub that 4.4.1 has not been published; is that >>> expected ? >>> - once logged-in I can't seem to access any of the 3 "System >>> settings" pages, they give me a 500, Is that expected ? (I haven't >>> managed >>> to get both my deployment working and django to spit out a traceback, >>> otherwise I would give up more info) >>> >>> I'm happy to start this as another thread if this is better suited. >>> -- >>> Matthias >>> >>> >>> >>> On Tue, 16 Apr 2019 at 10:12, Ben O'Steen wrote: >>> I should also make it clear that all of what I mentioned above is the default behaviour and doesn't need you to do anything more to make it work.
Re: [Arches] Docker-compose image have 404 for all static assets.
Rob G had similar issues running the test suite, but had an extra fail as well! Not sure what is going on but I think some tests need looking at possibly! Ben On Wed, 24 Apr 2019 at 05:13, Vincent Meijer wrote: > Nice! > Sounds like that is a regular assertion error and independent of the > environment, or does the test succeed locally? > > On Tue, Apr 23, 2019 at 6:46 PM Ben O'Steen wrote: > >> Good news, Bad news I'm afraid: >> >> Good news? the environment flag seems to have done the trick and the >> Elasticsearch container doesn't quit after running its checks. >> >> Bad news? There is a failing test: >> >> FAIL: Test bulk deleting of documents in Elasticsearch >> -- >> Traceback (most recent call last): >> File "/web_root/arches/tests/search/search_tests.py", line 66, in >> test_bulk_delete >> self.assertEqual(se.count(index='test'), 10) >> AssertionError: 11 != 10 >> >> >> https://cloud.docker.com/repository/registry-1.docker.io/benosteen/arches/builds/88c8a09d-9fa6-44f5-a86a-fc960ba2f327 >> >> >> >> On Tue, 23 Apr 2019 at 08:23, Ben O'Steen wrote: >> >>> That is an odd error, certainly works locally but not when docker hub >>> runs the test setup. >>> >>> One thing it could be is that if docker hub are using default EC2 >>> instances, they have the vm.max_map_count set too low for Elasticsearch. It >>> is high enough that Elasticsearch will boot but not enough to stop it >>> erroring out after a very short period. I've been using 'sudo sysctl -w >>> vm.max_map_count=262144' on the host to avoid this which is why it is not >>> erroring for me during Elasticsearch's bootstrap checks. >>> >>> We should be able to disable the checks (turn them from hard errors to >>> soft warnings in the logs) by passing the ES container >>> "discovery.type=single-node" as an environment variable. I'll try this on >>> my docker hub account and see if that can fix it. >>> >>> Ben >>> >>> On Tue, 23 Apr 2019 at 03:12, Vincent Meijer >>> wrote: >>> It seems there are problems with our automated docker builds, which is presumably the cause of the 4.4.1 tag not existing. Latest build of the master branch failed: the Elasticsearch endpoint cannot be reached during the unit tests. Failed to establish a new connection: [Errno -2] Name or service not known) https://cloud.docker.com/u/archesproject/repository/registry-1.docker.io/archesproject/arches/builds/ca27a312-4d02-4e1b-b65c-2f34cb22ef79 Not sure why this is, as the Elasticsearch container seems to be up and running during the test. Full command: run_tests Command: run_tests Testing if database server is up... Database server is up Testing if Elasticsearch is up... Elasticsearch is up However, the 4.4.1 build does not seem be have been triggered at all, and I'm at a loss as to why this hasn't happened... Possibly someone with more permissions than me could check the webhook settings in the Github repo? :) Vincent On Fri, Apr 19, 2019 at 12:40 AM Ben O'Steen wrote: > > - As for Docker 4.4.1 not being put onto Docker Hub, I'm not sure why > that is. I've been making my own images of the codebase in lieu of that. > > - I don't get the System settings errors you mention, though I am > using Arches based on a much more recent codebase (I created my Arches > base > image last week or so from the master branch). > > Ben > > On Tue, 16 Apr 2019 at 14:39, Matthias Bussonnier < > bussonniermatth...@gmail.com> wrote: > >> Thanks Ben, >> >> That was useful, I guess I got confused between DEV mode 8000 and >> PROD port 80, I got it to work now. >> >> 2 followup questions; now that I can see the website and login: >> - I see on dockerhub that 4.4.1 has not been published; is that >> expected ? >> - once logged-in I can't seem to access any of the 3 "System >> settings" pages, they give me a 500, Is that expected ? (I haven't >> managed >> to get both my deployment working and django to spit out a traceback, >> otherwise I would give up more info) >> >> I'm happy to start this as another thread if this is better suited. >> -- >> Matthias >> >> >> >> On Tue, 16 Apr 2019 at 10:12, Ben O'Steen wrote: >> >>> I should also make it clear that all of what I mentioned above is >>> the default behaviour and doesn't need you to do anything more to make >>> it >>> work. >>> >> -- > -- To post, send email to archesproject@googlegroups.com. To > unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. > For more information, visit > https://groups.google.com/d/forum/archesproject?hl=en > --- > You received this message because you are subscribed to the Google >
Re: [Arches] Docker-compose image have 404 for all static assets.
Nice! Sounds like that is a regular assertion error and independent of the environment, or does the test succeed locally? On Tue, Apr 23, 2019 at 6:46 PM Ben O'Steen wrote: > Good news, Bad news I'm afraid: > > Good news? the environment flag seems to have done the trick and the > Elasticsearch container doesn't quit after running its checks. > > Bad news? There is a failing test: > > FAIL: Test bulk deleting of documents in Elasticsearch > -- > Traceback (most recent call last): > File "/web_root/arches/tests/search/search_tests.py", line 66, in > test_bulk_delete > self.assertEqual(se.count(index='test'), 10) > AssertionError: 11 != 10 > > > https://cloud.docker.com/repository/registry-1.docker.io/benosteen/arches/builds/88c8a09d-9fa6-44f5-a86a-fc960ba2f327 > > > > On Tue, 23 Apr 2019 at 08:23, Ben O'Steen wrote: > >> That is an odd error, certainly works locally but not when docker hub >> runs the test setup. >> >> One thing it could be is that if docker hub are using default EC2 >> instances, they have the vm.max_map_count set too low for Elasticsearch. It >> is high enough that Elasticsearch will boot but not enough to stop it >> erroring out after a very short period. I've been using 'sudo sysctl -w >> vm.max_map_count=262144' on the host to avoid this which is why it is not >> erroring for me during Elasticsearch's bootstrap checks. >> >> We should be able to disable the checks (turn them from hard errors to >> soft warnings in the logs) by passing the ES container >> "discovery.type=single-node" as an environment variable. I'll try this on >> my docker hub account and see if that can fix it. >> >> Ben >> >> On Tue, 23 Apr 2019 at 03:12, Vincent Meijer >> wrote: >> >>> It seems there are problems with our automated docker builds, which is >>> presumably the cause of the 4.4.1 tag not existing. >>> >>> Latest build of the master branch failed: the Elasticsearch endpoint >>> cannot be reached during the unit tests. >>> Failed to establish a new connection: [Errno -2] Name or service not >>> known) >>> >>> https://cloud.docker.com/u/archesproject/repository/registry-1.docker.io/archesproject/arches/builds/ca27a312-4d02-4e1b-b65c-2f34cb22ef79 >>> >>> >>> Not sure why this is, as the Elasticsearch container seems to be up and >>> running during the test. >>> >>> Full command: run_tests >>> Command: run_tests >>> Testing if database server is up... >>> Database server is up >>> Testing if Elasticsearch is up... >>> Elasticsearch is up >>> >>> However, the 4.4.1 build does not seem be have been triggered at all, >>> and I'm at a loss as to why this hasn't happened... >>> Possibly someone with more permissions than me could check the webhook >>> settings in the Github repo? :) >>> >>> Vincent >>> >>> On Fri, Apr 19, 2019 at 12:40 AM Ben O'Steen wrote: >>> - As for Docker 4.4.1 not being put onto Docker Hub, I'm not sure why that is. I've been making my own images of the codebase in lieu of that. - I don't get the System settings errors you mention, though I am using Arches based on a much more recent codebase (I created my Arches base image last week or so from the master branch). Ben On Tue, 16 Apr 2019 at 14:39, Matthias Bussonnier < bussonniermatth...@gmail.com> wrote: > Thanks Ben, > > That was useful, I guess I got confused between DEV mode 8000 and PROD > port 80, I got it to work now. > > 2 followup questions; now that I can see the website and login: > - I see on dockerhub that 4.4.1 has not been published; is that > expected ? > - once logged-in I can't seem to access any of the 3 "System > settings" pages, they give me a 500, Is that expected ? (I haven't > managed > to get both my deployment working and django to spit out a traceback, > otherwise I would give up more info) > > I'm happy to start this as another thread if this is better suited. > -- > Matthias > > > > On Tue, 16 Apr 2019 at 10:12, Ben O'Steen wrote: > >> I should also make it clear that all of what I mentioned above is the >> default behaviour and doesn't need you to do anything more to make it >> work. >> > -- -- To post, send email to archesproject@googlegroups.com. To unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to archesproject+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. >>> -- >>> -- To post, send email to archesproject@googlegroups.com. To >>> unsubscribe, send email to
Re: [Arches] Docker-compose image have 404 for all static assets.
Good news, Bad news I'm afraid: Good news? the environment flag seems to have done the trick and the Elasticsearch container doesn't quit after running its checks. Bad news? There is a failing test: FAIL: Test bulk deleting of documents in Elasticsearch -- Traceback (most recent call last): File "/web_root/arches/tests/search/search_tests.py", line 66, in test_bulk_delete self.assertEqual(se.count(index='test'), 10) AssertionError: 11 != 10 https://cloud.docker.com/repository/registry-1.docker.io/benosteen/arches/builds/88c8a09d-9fa6-44f5-a86a-fc960ba2f327 On Tue, 23 Apr 2019 at 08:23, Ben O'Steen wrote: > That is an odd error, certainly works locally but not when docker hub runs > the test setup. > > One thing it could be is that if docker hub are using default EC2 > instances, they have the vm.max_map_count set too low for Elasticsearch. It > is high enough that Elasticsearch will boot but not enough to stop it > erroring out after a very short period. I've been using 'sudo sysctl -w > vm.max_map_count=262144' on the host to avoid this which is why it is not > erroring for me during Elasticsearch's bootstrap checks. > > We should be able to disable the checks (turn them from hard errors to > soft warnings in the logs) by passing the ES container > "discovery.type=single-node" as an environment variable. I'll try this on > my docker hub account and see if that can fix it. > > Ben > > On Tue, 23 Apr 2019 at 03:12, Vincent Meijer > wrote: > >> It seems there are problems with our automated docker builds, which is >> presumably the cause of the 4.4.1 tag not existing. >> >> Latest build of the master branch failed: the Elasticsearch endpoint >> cannot be reached during the unit tests. >> Failed to establish a new connection: [Errno -2] Name or service not >> known) >> >> https://cloud.docker.com/u/archesproject/repository/registry-1.docker.io/archesproject/arches/builds/ca27a312-4d02-4e1b-b65c-2f34cb22ef79 >> >> >> Not sure why this is, as the Elasticsearch container seems to be up and >> running during the test. >> >> Full command: run_tests >> Command: run_tests >> Testing if database server is up... >> Database server is up >> Testing if Elasticsearch is up... >> Elasticsearch is up >> >> However, the 4.4.1 build does not seem be have been triggered at all, and >> I'm at a loss as to why this hasn't happened... >> Possibly someone with more permissions than me could check the webhook >> settings in the Github repo? :) >> >> Vincent >> >> On Fri, Apr 19, 2019 at 12:40 AM Ben O'Steen wrote: >> >>> >>> - As for Docker 4.4.1 not being put onto Docker Hub, I'm not sure why >>> that is. I've been making my own images of the codebase in lieu of that. >>> >>> - I don't get the System settings errors you mention, though I am using >>> Arches based on a much more recent codebase (I created my Arches base image >>> last week or so from the master branch). >>> >>> Ben >>> >>> On Tue, 16 Apr 2019 at 14:39, Matthias Bussonnier < >>> bussonniermatth...@gmail.com> wrote: >>> Thanks Ben, That was useful, I guess I got confused between DEV mode 8000 and PROD port 80, I got it to work now. 2 followup questions; now that I can see the website and login: - I see on dockerhub that 4.4.1 has not been published; is that expected ? - once logged-in I can't seem to access any of the 3 "System settings" pages, they give me a 500, Is that expected ? (I haven't managed to get both my deployment working and django to spit out a traceback, otherwise I would give up more info) I'm happy to start this as another thread if this is better suited. -- Matthias On Tue, 16 Apr 2019 at 10:12, Ben O'Steen wrote: > I should also make it clear that all of what I mentioned above is the > default behaviour and doesn't need you to do anything more to make it > work. > -- >>> -- To post, send email to archesproject@googlegroups.com. To >>> unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. >>> For more information, visit >>> https://groups.google.com/d/forum/archesproject?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Arches Project" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to archesproject+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> -- To post, send email to archesproject@googlegroups.com. To >> unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. >> For more information, visit >> https://groups.google.com/d/forum/archesproject?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Arches Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to
Re: [Arches] Docker-compose image have 404 for all static assets.
That is an odd error, certainly works locally but not when docker hub runs the test setup. One thing it could be is that if docker hub are using default EC2 instances, they have the vm.max_map_count set too low for Elasticsearch. It is high enough that Elasticsearch will boot but not enough to stop it erroring out after a very short period. I've been using 'sudo sysctl -w vm.max_map_count=262144' on the host to avoid this which is why it is not erroring for me during Elasticsearch's bootstrap checks. We should be able to disable the checks (turn them from hard errors to soft warnings in the logs) by passing the ES container "discovery.type=single-node" as an environment variable. I'll try this on my docker hub account and see if that can fix it. Ben On Tue, 23 Apr 2019 at 03:12, Vincent Meijer wrote: > It seems there are problems with our automated docker builds, which is > presumably the cause of the 4.4.1 tag not existing. > > Latest build of the master branch failed: the Elasticsearch endpoint > cannot be reached during the unit tests. > Failed to establish a new connection: [Errno -2] Name or service not known) > > > https://cloud.docker.com/u/archesproject/repository/registry-1.docker.io/archesproject/arches/builds/ca27a312-4d02-4e1b-b65c-2f34cb22ef79 > > > Not sure why this is, as the Elasticsearch container seems to be up and > running during the test. > > Full command: run_tests > Command: run_tests > Testing if database server is up... > Database server is up > Testing if Elasticsearch is up... > Elasticsearch is up > > However, the 4.4.1 build does not seem be have been triggered at all, and > I'm at a loss as to why this hasn't happened... > Possibly someone with more permissions than me could check the webhook > settings in the Github repo? :) > > Vincent > > On Fri, Apr 19, 2019 at 12:40 AM Ben O'Steen wrote: > >> >> - As for Docker 4.4.1 not being put onto Docker Hub, I'm not sure why >> that is. I've been making my own images of the codebase in lieu of that. >> >> - I don't get the System settings errors you mention, though I am using >> Arches based on a much more recent codebase (I created my Arches base image >> last week or so from the master branch). >> >> Ben >> >> On Tue, 16 Apr 2019 at 14:39, Matthias Bussonnier < >> bussonniermatth...@gmail.com> wrote: >> >>> Thanks Ben, >>> >>> That was useful, I guess I got confused between DEV mode 8000 and PROD >>> port 80, I got it to work now. >>> >>> 2 followup questions; now that I can see the website and login: >>> - I see on dockerhub that 4.4.1 has not been published; is that >>> expected ? >>> - once logged-in I can't seem to access any of the 3 "System settings" >>> pages, they give me a 500, Is that expected ? (I haven't managed to get >>> both my deployment working and django to spit out a traceback, otherwise I >>> would give up more info) >>> >>> I'm happy to start this as another thread if this is better suited. >>> -- >>> Matthias >>> >>> >>> >>> On Tue, 16 Apr 2019 at 10:12, Ben O'Steen wrote: >>> I should also make it clear that all of what I mentioned above is the default behaviour and doesn't need you to do anything more to make it work. >>> -- >> -- To post, send email to archesproject@googlegroups.com. To >> unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. >> For more information, visit >> https://groups.google.com/d/forum/archesproject?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Arches Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to archesproject+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > -- To post, send email to archesproject@googlegroups.com. To unsubscribe, > send email to archesproject+unsubscr...@googlegroups.com. For more > information, visit https://groups.google.com/d/forum/archesproject?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Arches Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to archesproject+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- To post, send email to archesproject@googlegroups.com. To unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to archesproject+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Arches] Docker-compose image have 404 for all static assets.
It seems there are problems with our automated docker builds, which is presumably the cause of the 4.4.1 tag not existing. Latest build of the master branch failed: the Elasticsearch endpoint cannot be reached during the unit tests. Failed to establish a new connection: [Errno -2] Name or service not known) https://cloud.docker.com/u/archesproject/repository/registry-1.docker.io/archesproject/arches/builds/ca27a312-4d02-4e1b-b65c-2f34cb22ef79 Not sure why this is, as the Elasticsearch container seems to be up and running during the test. Full command: run_tests Command: run_tests Testing if database server is up... Database server is up Testing if Elasticsearch is up... Elasticsearch is up However, the 4.4.1 build does not seem be have been triggered at all, and I'm at a loss as to why this hasn't happened... Possibly someone with more permissions than me could check the webhook settings in the Github repo? :) Vincent On Fri, Apr 19, 2019 at 12:40 AM Ben O'Steen wrote: > > - As for Docker 4.4.1 not being put onto Docker Hub, I'm not sure why that > is. I've been making my own images of the codebase in lieu of that. > > - I don't get the System settings errors you mention, though I am using > Arches based on a much more recent codebase (I created my Arches base image > last week or so from the master branch). > > Ben > > On Tue, 16 Apr 2019 at 14:39, Matthias Bussonnier < > bussonniermatth...@gmail.com> wrote: > >> Thanks Ben, >> >> That was useful, I guess I got confused between DEV mode 8000 and PROD >> port 80, I got it to work now. >> >> 2 followup questions; now that I can see the website and login: >> - I see on dockerhub that 4.4.1 has not been published; is that >> expected ? >> - once logged-in I can't seem to access any of the 3 "System settings" >> pages, they give me a 500, Is that expected ? (I haven't managed to get >> both my deployment working and django to spit out a traceback, otherwise I >> would give up more info) >> >> I'm happy to start this as another thread if this is better suited. >> -- >> Matthias >> >> >> >> On Tue, 16 Apr 2019 at 10:12, Ben O'Steen wrote: >> >>> I should also make it clear that all of what I mentioned above is the >>> default behaviour and doesn't need you to do anything more to make it work. >>> >> -- > -- To post, send email to archesproject@googlegroups.com. To unsubscribe, > send email to archesproject+unsubscr...@googlegroups.com. For more > information, visit https://groups.google.com/d/forum/archesproject?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Arches Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to archesproject+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- To post, send email to archesproject@googlegroups.com. To unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to archesproject+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Arches] Docker-compose image have 404 for all static assets.
- As for Docker 4.4.1 not being put onto Docker Hub, I'm not sure why that is. I've been making my own images of the codebase in lieu of that. - I don't get the System settings errors you mention, though I am using Arches based on a much more recent codebase (I created my Arches base image last week or so from the master branch). Ben On Tue, 16 Apr 2019 at 14:39, Matthias Bussonnier < bussonniermatth...@gmail.com> wrote: > Thanks Ben, > > That was useful, I guess I got confused between DEV mode 8000 and PROD > port 80, I got it to work now. > > 2 followup questions; now that I can see the website and login: > - I see on dockerhub that 4.4.1 has not been published; is that expected > ? > - once logged-in I can't seem to access any of the 3 "System settings" > pages, they give me a 500, Is that expected ? (I haven't managed to get > both my deployment working and django to spit out a traceback, otherwise I > would give up more info) > > I'm happy to start this as another thread if this is better suited. > -- > Matthias > > > > On Tue, 16 Apr 2019 at 10:12, Ben O'Steen wrote: > >> I should also make it clear that all of what I mentioned above is the >> default behaviour and doesn't need you to do anything more to make it work. >> > -- -- To post, send email to archesproject@googlegroups.com. To unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to archesproject+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Arches] Docker-compose image have 404 for all static assets.
Thanks Ben, That was useful, I guess I got confused between DEV mode 8000 and PROD port 80, I got it to work now. 2 followup questions; now that I can see the website and login: - I see on dockerhub that 4.4.1 has not been published; is that expected ? - once logged-in I can't seem to access any of the 3 "System settings" pages, they give me a 500, Is that expected ? (I haven't managed to get both my deployment working and django to spit out a traceback, otherwise I would give up more info) I'm happy to start this as another thread if this is better suited. -- Matthias On Tue, 16 Apr 2019 at 10:12, Ben O'Steen wrote: > I should also make it clear that all of what I mentioned above is the > default behaviour and doesn't need you to do anything more to make it work. > -- -- To post, send email to archesproject@googlegroups.com. To unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to archesproject+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Arches] Docker-compose image have 404 for all static assets.
I should also make it clear that all of what I mentioned above is the default behaviour and doesn't need you to do anything more to make it work. -- -- To post, send email to archesproject@googlegroups.com. To unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to archesproject+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Arches] Docker-compose image have 404 for all static assets.
How the static files are served depends on a few things. What is the DJANGO_MODE variable set to in the docker-compose.yml that you are using? (NB if you also have an .env file in that directory, that may be overwriting this issue) If it is PROD, then the command to collect static files should copy them all to the directory "/static_root" by default. It will look for them in the directories specified in the STATICFILES_DIRS list in settings.py. This should be marked as a persisted volume in your docker compose configuration: " - arches-static:/static_root". The nginx container also has access to this volume, which it mounts as '/www/static' and serves as " http://host/static/...;. The Arches instance will be available from http://host:80/ (eg http://localhost ). The Arches instance will be served from the arches container on port 8000, but you should not be accessing this directly. If DJANGO_MODE is DEV, then the django runserver process is used to serve the contents, and it will be available on port 8000. This will also serve the static files as well, and you should be able to access the Arches instance from http://host:8000 (eg http://localhost:8000). Ben On Tue, 16 Apr 2019 at 09:24, Matthias Bussonnier < bussonniermatth...@gmail.com> wrote: > Hello, > > I am trying to deploy Arches for our local institution, I'm trying to go > through the instruction [1], on how to run in docker. > Most instruction appear to work so far (a couple of couchdb and > elasticsearch warning which I'm going to assume are for first run, > But when accessing the local install, I get greeted with 404 on any static > resource situated under /media/. > > Arches does seem to properly copy assets : > > > arches | Copying > '/web_root/arches/arches/app/media/packages/font-awesome/README.md' > (and alike), > > And does this the requests ( so it's likely not a nginx thing): > > > arches | 172.21.0.1 - - [16/Apr/2019:11:18:40 -0500] "GET > /media/css/unify.css HTTP/1.1" 404 93 "http://localhost:8000/; > > > I'm i'm starting to run out of ideas of what could cause this, and would > love some guidance – which I would be happy to contribute in the form of > pull-requests again the main repository. > > I'm tried the master (a20525c1828 as of April 11th) and 4.4.1, making > sure to update docker-compose to point at my locally built docker image, > and pruning docker volumes. > > Thanks, > -- > 1: > https://github.com/archesproject/arches/tree/master/docker#setting-up-your-own-arches-project > > -- > -- To post, send email to archesproject@googlegroups.com. To unsubscribe, > send email to archesproject+unsubscr...@googlegroups.com. For more > information, visit https://groups.google.com/d/forum/archesproject?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Arches Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to archesproject+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- To post, send email to archesproject@googlegroups.com. To unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to archesproject+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
