-
Notifications
You must be signed in to change notification settings - Fork 490
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
3937 rewrite installer in python again #6484
Conversation
Using native python PostgresQL client allows us to bypass using psql - thus saving us all the trouble locating the right psql executable on the system. (ref. #3937)
…atabase already exists. (#3937)
… warning from the old installer. (#3937)
…smtp server entered. (#3937)
…e for making a distribution zip bundle. (#3937)
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.
Overall, I think this looks good so I'm sending it to QA. That said, her are some (minor) suggestions, questions, and comments. @landreev should feel free to pull this out of QA if he wants to work on any of this.
Suggestions:
- in the Perl install script, mention the new Python script
- in requirements.txt, put version of psycopg2
- consider recommending Python 3's venv (virtual environment)
Questions:
- 10.5072 is configured but when they contact DataCite do they get a new authority for testing?
- Any thoughts on when we'll stop supporting the Perl installer?
Comments:
- @donsizemore is planning on testing the new Python installer as part of support new Python 3 installer (formerly in Perl) dataverse-ansible#139
- I'm not sure if anyone will miss the "podName" stuff but I guess it doesn't hurt to leave it in there. Recently @poikilotherm mentioned OpenShift (which podName was added for) at Test for OpenShift 4.x+ compatibility gdcc/dataverse-kubernetes#129
- It would be nice to support Windows dev environments some day. Out of scope for now.
@donsizemore, @landreev mentioned that you were discussing this quite a bit. Your review here would be very appreciated if you have the time to do so. Thanks in advance! |
@landreev what's the relationship between default.config and interactive.config? I popped the latter into Ansible as a template but the install script seems to want default.config's structure instead. I can swap out the templates, but default.config has 30 lines of content while interactive.config has 47. It's looking like I'll need both? |
(@pdurbin mentioned he had already answered this, but just to clarify and document this here:) Yes, the script needs both.
Thinking about it, there's no need to load and parse this file at all, when the installer is running in the non-interactive mode. I'll add an |
@landreev one more question: previously the dataverse installer captured the output of glassfish-setup into glassfish-setup.out — do we want to keep that, or offer an output file flag? helpful for debugging... |
Nobody asked for it, but my 2 cents: as long as @donsizemore is not relying on the OpenShift workarounds, feel free to let anything related to it RIP in good ol' Perl version. @pdurbin and I where going to cut out the Openshift stuff from the guide anyway and move all cloud/container regarding OpenShift to dataverse-k8s. See also gdcc/dataverse-kubernetes#129 |
…ental python installer script. (#3937)
Oh, I guess I'll throw in a few cents too. Back when the (Perl) installer required root I wrote a little shell script called "devinstall" at f181543 that seemed to work for me as an alternative. These days you can also find a slight variation of this script at https://github.com/IQSS/dataverse/blob/v4.18.1/scripts/deploy/phoenix.dataverse.org/install These days I just use the standard installer for dev environments rather than my "devinstall" script. But on servers, I use dataverse-ansible, which doesn't use the old Perl script. I guess if dataverse-ansible uses the new Python script I'll start using it on servers. I'm not exactly sure where I'm going with this. I guess I'm happy that the new Python script will be exercised regularly by dataverse-ansible. I think somewhere in docker-aio there's an option to use the old Perl script but I'm not in the habit of using docker-aio. In short, I'm glad the new code will be tested regularly, at least the non-interactive mode. |
dataverse-ansible now deploys the 4.18.1 release normally using the python3 installer instead of a bunch of calls I had broken out into Ansible-ese. I did keep the JDBC jar placement in Ansible's realm as that's a configurable switch for testing of newer jars. If anyone would like to give the work-in-progress a whirl, it's https://github.com/IQSS/dataverse-ansible/tree/139_python3_installer |
Issues found so far:
|
Yay! I'll give it a try.
|
@donsizemore wow! Looking at https://github.com/IQSS/dataverse-ansible/compare/139_python3_installer I see you've been busy!! Thanks!! 🎉 |
All set testing, passing back to dev. |
… library dir from /modules to /lib;
…ded; if you really really have to use v2. - 2.7+ required) (#3937)
@kcondon, I addressed the feedback below. With the exception of the old-style default.config - I figured it wasn't necessary, just because of how unlikely it is to happen to anyone else. (and easy to fix if it does :)
|
My thought was to release it as beta/experimental in the next release; invite people to give it a try; incorporate any feedback we receive and then switch to it as the default installer for the release after that. This is something we may want to discuss as a team at some point during the next release cycle. I personally would be ok to say that you have to be somewhat of a sysadmin/be comfortable with python, etc. to install Dataverse. |
What this PR does / why we need it:
New Installer Implementation, in Python
Which issue(s) this PR closes:
Closes #3937
Special notes for your reviewer:
Suggestions on how to test this:
Does this PR introduce a user interface change?:
Is there a release notes update needed for this change?:
Additional documentation: