JeDI Integration

[JoelProminic]

@JustinProminic is pushing to get JeDI integrated into the SHI provisioners. @PanProminic and I have been working on the provisioners for a while in the private repository, so hopefuly this side of the updates will be relatively simple.

Branch: features/issue_14_domino_jedi

Tasks (do not necessarily need to be done in this order)

• Official release for JeDI
• Copy artifacts to production location (public server or artifacts in repository)
• Cleanup JeDI directory tempalte
• Finalize password logic
• Copy ansible scripts to hcl_roles
• Automatically switch over from nashed service to JeDI
• Review scripts with @MarkProminic
• Update provisioners in Super.Human.Installer

My full writeup:

Here are the remaining tasks I see for the JeDI provisioners. Justin you may want to review the password section - are you going to have similar complaints in emergencies when you need to lookup the updated password?

Joel: Create official release for JeDI in GitHub

• Revisit GitHub Actions
• Deploy to production host and test with JediJSP

Joel/Mark: Copy the "production" artifacts to a public server. I will talk to Mark about an appropriate server

• Current artifacts:
  • files/jedi (not cleaned yet): https://domino-49.prominic.net/jedi-server-private/test/jedi-github-temp.zip
    . jedi.jar (can be deployed as part of the GitHub actions): https://domino-49.prominic.net/jedi-server-private/test/jedi-github-temp.jar
• Mark's initial provisioners used downloads.prominic.net, but they require the passwords: https://github.com/prominic/prominic_roles/blob/main/roles/prominic_jedi/tasks/main.yml#L41-L52
• OPTIONAL: Update the GitHub actions to deploy to this server instead of domino-49
• Alternative - store the artifacts in the GitHub repository instead.

Joel/Pan: Cleanup main jedi.zip template to remove obvious VM-specific files. Pan has a way to test the new template without updating

Pan: Customize JeDI password, or update it to use host password

• Pan updated this to hard-code the default startcloud credentials
• Remove the legacy credentials.
• Optional: Dynamically add new credentials. Some posibilities
  • Update the exisitng users.cfg. Pan reports that the code for this is out-of-date, and needs refactoring.
  • Use the Linux passwords file instead of the built-in file

Joel/Mark: Copy Pan's ansible scripts into the SHI provisioners (hcl_roles?). This is complicated enough that we may want a branch:

• Provisioners to update. Note that these are public provisioners to be used by Super.Human.Installer:
  • https://github.com/STARTcloud/hcl_domino_standalone_provisioner
  • https://github.com/STARTcloud/hcl_domino_additional_provisioner
• Pan's scripts: https://github.com/DominoJedi/jedi-server-private/tree/main/roles/domino_jedi
• Optional: Review and update to Mark's standards
• Use artifacts instead of submodule
  • Should already be supported by Pan's scripts, though we may want to change paths
• Joel/Mark: Disable the nashed service after installing JeDI
  • Mark reported that he may have a way to keep using the nashed service, but let JeDI manage the domino instance.
• Binding the output files in JeDI:
  • Restart the Domino server with JeDI
  • Use this workaround to use the files from the nashed service: https://github.com/DominoJedi/jedi-server-private/issues/3#issuecomment-2542426873
• Joel: Merge domino_java_tools updates. I was working on this last week, and it was waiting on some final tests

Piotr: Update provisioners in Super.Human.Installer

• includes additional provisioners
• This should be done after we finish the other updates

[JoelProminic]

I copied the roles that @PanProminic worked on to the branch.

TODO:

• For now, this is still using the artifacts on domino-49. This allows me to test, but the artifacts will need to be moved to the repository or to a public server.
• Add some logic to detect if JeDI was already installed?
• Add some logic to work with the nashed service. For now, the nashed service needs to be disabled. I found that when I restarted the VM, both services started and were killing the server started by the other service. In the longer term, @JustinProminic requested that we make an update to JeDI to let it coexist with the nashed service, but this is a future task.

UPDATE: If you want to test this, you need to add the startcloud.hcl_roles.domino_jedi role to your Hosts.yml. This should be run after all the domino roles that depend on the nashed service are completed. I put it after the nomadweb role in my test:

      - name: startcloud.hcl_roles.domino_nomadweb
        vars:
          run_tasks: true

      # JeDI
      - name: startcloud.hcl_roles.domino_jedi

[JoelProminic]

I added code to disable the nashed service. I noticed that the jedi service wasn't automatically starting Domino on reboot, so I fixed this.

I am working on cleaning the jedi template now.

I also noticed that we were using an "old" copy of jedi.jar in our tests. I'm also working on getting this updated.

[JoelProminic]

I created a release for JeDI, based on the code I have been testing with the new provisioners. I need to revisit the GitHub action updates later - I have been having trouble with the self-hosted runners this week:
https://github.com/DominoJedi/jedi-server-private/releases/tag/v2.11

I put the public artifacts here:
https://public-artifacts.prominic.net/jedi/jedi.jar
https://public-artifacts.prominic.net/jedi/jedi.zip

I updated the URLs in defaults/main.yml, and I'll commit my changes once I confirm this.

Otherwise, this should be ready for a merge.