-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Align to GeoNode master (4.2.0) and improve/fix docker initialization #457
Conversation
…bles (starting the process at least)
@afabiani these are quite good changes! However, the PR raises a maintenance question: What do you actually recommend when users have to decide between a GeoNode Fork or the creation of a separate Geonode project via geonode-project template? The main problem I see is to keep track of all the changes you make on this repository (e.g. those within this PR). Once a project has been created, it gets detached from version control. If a user decides to upgrade their GeoNode project, they would have to follow the commit history and apply all changes manually, right? Wouldn't it be better to just use a GeoNode fork so the changes become visible once you do a merge/pull? Is there is a discussion (issue/documentation) about Forking vs. GeoNode-Project somewhere? Some good practice guidance would be helpful too. I'd be happy for any pointer :-) |
Those changes won't ba backported. Those will be eventually part of the 4.2.0 train, currently under development. |
Ok .. but what about mainaining a project which got generated from the geonode-project repository? When upgrading to 4.2.0 .. I would have to go through the commit history and apply the changes manually on that project. Or do I miss something? |
The idea would be to update the documentation of the 4.2.0 release with a specific section for this topic. However we can open a discussion on the mailing list to further investigate the problem and hear from the community if there are some suitable proposals/ideas. |
You mean edit: mail address .. geonode-devel is the right one -- in fact I only found the geonode-devel-requests address in my inbox |
@afabiani my email awaits approval 🤷♂️ |
docker/geoserver/tasks.py
Outdated
# | ||
######################################################################### | ||
import os | ||
import os |
Check notice
Code scanning / CodeQL
Module is imported more than once
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove redundant import
…o use the correct variable for the "geofenceDataSource.username"
GEOSERVER_ADMIN_USER = os.getenv("GEOSERVER_ADMIN_USER", "admin") | ||
GEOSERVER_ADMIN_PASSWORD = os.getenv("GEOSERVER_ADMIN_PASSWORD", "geoserver") | ||
GEOSERVER_FACTORY_PASSWORD = os.getenv("GEOSERVER_FACTORY_PASSWORD", "geoserver") | ||
geoserver_rest_baseurl = f"http://localhost:{GEOSERVER_LB_PORT}/geoserver/rest" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a strayed localhost, I suspect?!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope it's ok. It will always refer to the local container.
@ridoo if you agree I would merge the PR |
e37731a
to
89bc888
Compare
@giohappy if it is ok for you, I'd take a deeper look later this day, before just saying "ok". |
fdee9e6
to
89bc888
Compare
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
613dfbc
to
89bc888
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I finished review .. however, I touched some parts which relate to Geonode core as well (the PR puts the changes made upstream here) .
However, I did not want to block the PR.
docker kill $(docker ps -q); docker rm $(docker ps -a -q); docker rmi $(docker images -q); docker volume ls -qf dangling=true | xargs -r docker volume rm; docker system prune -a | ||
docker volume prune |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is quite dangerous as it removes everything non-geonode related, too! To my experience first-time users do not understand the implications immediately. Having a cleaned Docker setup is afterwards, well, .. surprising, at least.
Leverage the --filter
flag:
# delete all containers with name including "thuenen"
docker rm $(docker ps -aq --filter=name=thuenen)
# delete all volumes with name including "thuenen"
docker volume rm $(docker volume ls -q --filter name=thuenen)
# delete all images having a `4.0` tag starting with `geonode`
docker rmi $(docker images -q --filter=reference='geonode/*:4.0')
docker/geoserver/tasks.py
Outdated
# | ||
######################################################################### | ||
import os | ||
import os |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove redundant import
This PR introduces improvements and fixes to docker-compose and initialization scripts in general:
Some implementation details:
DOCKERHOST
andDOCKER_HOST_IP
variables removed as useless and misleading. Instead, it exposedNGINX_BASE_URL
which was calculated automatically and badly.The variables
are important, they are used by
NGINX
to create the upstreamproxyPass
and by GeoServer to create the internalOAuth2
endpoints. They represent the name and port of the GeoNode and GeoServer containers. In general it is not necessary to change them, but in an environment likeMicrosoft Azure
these must be set to the address of thesubnet
as the names are not internally resolved.Increased
MAX_DOCUMENT_SIZE=200
because the previous default of2Mb
did not allow rendering even one document.Updated
create-envfile.py
to also enablestaging
mode to testHTTPS
onlocalhost
, which was previously totally ignored.Removed useless stuff and started it from
geonode/geonode-base:latest-ubuntu-22.10
Added a
Quick Start
section withdocker
Fixed healthchecks which are now faster and more efficient and switched Django -> GeoServer startup dependency, because it's the Django entrypoint that sets
OAutg2
parameters in theGEOSERVER_DATA_DIR
before it starts.Updated to
POSTgresql 15
Enabled
proxyPass
instead ofuwsgiPass
because we setheaders
correctly ingeonode.conf
only withproxyPass
Fixed the
.sh
to setOAuth2
which previously worked badly and only partially checking when there was thelocalhost
value. Now they update everything and always.Made
proxy passes
dynamicset $upstream $GEOSERVER_LB_HOST_IP:$GEOSERVER_LB_PORT;
set $upstream $GEONODE_LB_HOST_IP:$GEONODE_LB_PORT;
Updated the GeoServer conf so that the GUI works fine behind any proxy.
A general reformat to the
black
codeVersion bump
from
4.0.0.final
to4.2.0.dev