Moonshine-IDE / Super.Human.Installer

Super.Human.Installer helps you install the latest and greatest HCL Domino technologies easily.
https://superhumaninstaller.com/
Other
2 stars 0 forks source link

Overriding Installers and Versions #76

Closed JoelProminic closed 1 year ago

JoelProminic commented 1 year ago

When we tried to test with a newer version of NomadWeb (1.0.8), we got a crash (#75) with error using the old version number (1.0.6):

TASK [domino-nomadweb : Extracting NomadWeb from nomad-server-1.0.6-for-domino-1202-linux.tgz] ***

[2023-06-20 15:06:33][DEBUG][Source/superhuman/server/Server.hx:1147] [Server(8699)]: Vagrant up: fatal: [8699--demo.STARTcloud.com]: FAILED! => {"changed": false, "msg": "Source '/vagrant/installers/nomadweb/archives/nomad-server-1.0.6-for-domino-1202-linux.tgz' does not exist"}

This is because the installer name is hard-coded. This is then used when checking the installer locations (example).

nomadweb_archive: nomad-server-1.0.6-for-domino-1202-linux.tgz
nomadweb_version: 1.0.6

We discussed this with @MarkProminic, and his intention was to allow this to be overridden in Hosts.yml. In order to do this, we need to set values for the above properties in the vars section. For example:

    vars:
      ...
      debug_all: true
      # change nomad version
      nomadweb_archive: ::NOMAD_INSTALLER::
      nomadweb_version: ::NOMAD_VERSION::

The Haxe code would need to be updated to replace the new insertion parameters ::NOMAD_INSTALLER:: ::NOMAD_VERSION::. The installer name would be determined by the file selected by the user. The version would need to be parsed from the filename, defaulting to value like "UNKNOWN" if it can't be parsed. For the Nomad example, the version is only used in labels, so it doesn't matter. In theory we could need custom logic for different installer versions, though.

Note that this same issue will likely trigger for the other user-provided installers, so we would need to update the template with the appropriate properties for each installer.

JoelProminic commented 1 year ago

@MarkProminic noted that if we can confirm that the user selected the expected version of Nomad, we could exclude the variable overrides. In that case, we could handle the variables like this, where ::NOMAD_VARS:: could be replaced by any empty string or the above properties:

    vars:
      ...
      debug_all: true
      ::NOMAD_VARS::

In my opinion, this solution seems unnecessarily complicated. I think it is better to just always write the installer and version properties, like I showed above.

piotrzarzycki21 commented 1 year ago

@MarkProminic @JoelProminic I have figure out on SHI what to change to apply installers picked up by the user. In order to test it I have changed locally my demo tasks 0.1.17 - everything worked nicely. Please check my properties based on screenshot. The question right now is where changes in demo-tasks should take place - should it be as part of next version 0.1.18 or still 0.1.17 ? I'm assuming all of these changes should be done by you Mark in your repository ?

List of files which has been changed locally:

Screenshot 2023-06-30 at 13 15 02
piotrzarzycki21 commented 1 year ago

Additionally I didn't bother about versions of each installer - what was hardcoded stays as it was. I'm not sure how to resolve problems with passing the right version, because user pickup file and there is no other option. I can of course read name of the files and try to extract version, but it won't be too perfect.

piotrzarzycki21 commented 1 year ago

The next step would for me take care of Hotfix and Fixpack for Domino - I think I need to have more discussion with Mark what properties need to be updated, but this can be for the laters work.

MarkProminic commented 1 year ago

@JoelProminic Correct me if I mis-remember our conversation from the other day, but like I mentioned in issue 77, I was going to take the current hosts.template.yml that is in SHI, and copy it over to my repo, and begin to fill out the "vars:" section, with the variables in the format below. I believe this is the preferred format you wanted this in:

    vars:
      ...
      debug_all: true
      # change nomad version
      nomadweb_archive: ::NOMAD_INSTALLER::
      nomadweb_version: ::NOMAD_VERSION::

One question I have, is if I expose a new variable, ie a new Domino Project comes along, and I try something like this:

    vars:
      ...
      debug_all: true
      # change nomad version
      nomadweb_archive: ::NOMAD_INSTALLER::
      nomadweb_version: ::NOMAD_VERSION::
      # change domino project x
      domprojx_archive: ::DOMPROJX_INSTALLER::
      domprojx_version: ::DOMPROJX_VERSION::

Whether or not Haxe will have an issue with the interpolation of a undefined variable. If we can set that behavior to always write space or nothing, the default variables I define in the roles would takeover. So if someone can confirm that behavior and if its modifiable that will mean that there will be no need to manually transcribe new features and changes into Hosts.template.yml

MarkProminic commented 1 year ago

For example, If we can make this into a variable/checksum map, we can know what version the user is using.

MarkProminic commented 1 year ago

@piotrzarzycki21

You didn't need to modify the main.yml for all the defaults folder, you simply just needed to redefine/override them via the Hosts.yml.

So I would expect the section on the right of your screenshot, in the Hosts.yml, to work without having to modify any of the other defaults/main.yml files.

piotrzarzycki21 commented 1 year ago

@piotrzarzycki21

You didn't need to modify the main.yml for all the defaults folder, you simply just needed to redefine/override them via the Hosts.yml.

So I would expect the section on the right of your screenshot, in the Hosts.yml, to work without having to modify any of the other defaults/main.yml files.

Understand. I don't have time test this, but I have run dev build - once it's ready it will contains my changes - if someone just modify Hosts.yml file manually at some point will be able to test whether it's working. I check that myself on Monday. Link to build if someone wanted to test.

piotrzarzycki21 commented 1 year ago

@JoelProminic Correct me if I mis-remember our conversation from the other day, but like I mentioned in issue 77, I was going to take the current hosts.template.yml that is in SHI, and copy it over to my repo, and begin to fill out the "vars:" section, with the variables in the format below. I believe this is the preferred format you wanted this in:

    vars:
      ...
      debug_all: true
      # change nomad version
      nomadweb_archive: ::NOMAD_INSTALLER::
      nomadweb_version: ::NOMAD_VERSION::

One question I have, is if I expose a new variable, ie a new Domino Project comes along, and I try something like this:

    vars:
      ...
      debug_all: true
      # change nomad version
      nomadweb_archive: ::NOMAD_INSTALLER::
      nomadweb_version: ::NOMAD_VERSION::
      # change domino project x
      domprojx_archive: ::DOMPROJX_INSTALLER::
      domprojx_version: ::DOMPROJX_VERSION::

Whether or not Haxe will have an issue with the interpolation of a undefined variable. If we can set that behavior to always write space or nothing, the default variables I define in the roles would takeover. So if someone can confirm that behavior and if its modifiable that will mean that there will be no need to manually transcribe new features and changes into Hosts.template.yml

@MarkProminic If in Hosts.template.yml exists property which I didn't map here - In the end you will have this kind of entry in final Hosts.yml:

domprojx_version: ::DOMPROJX_VERSION::

piotrzarzycki21 commented 1 year ago

I have just updated Hosts.template.yml with properties and it's working great with new development release build. I will continue to figure out how to fix fixpack for Domino.

piotrzarzycki21 commented 1 year ago

@piotrzarzycki21

You didn't need to modify the main.yml for all the defaults folder, you simply just needed to redefine/override them via the Hosts.yml.

So I would expect the section on the right of your screenshot, in the Hosts.yml, to work without having to modify any of the other defaults/main.yml files.

I have just pushed changes to Hosts.template.yml file for demo tasks 0.1.17 - I will try to figure out changes on my sight to have working fixpack as well. Once I do that I suggest release version and start work on proper improvement of 0.1.18 and upgrade on my sight.

JoelProminic commented 1 year ago

I did a test on Monday after renaming all of the installers:

mismatch_Domino_12.0.1_Linux_English.tar
mismatch_Domino_12.0.2_Linux_English.tar
mismatch_Domino_1202FP1_Linux.tar
mismatch_Domino_REST_API_V1_Installer.tar.gz
mismatch_HCL_Verse_3.0.0.zip
mismatch_Leap-1.0.5.zip
mismatch_Traveler_12.0.2_Linux_ML.tar.gz
mismatch_domino-appdev-pack-1.0.15.tgz
mismatch_nomad-server-1.0.8-for-domino-1202-linux.tgz

Everything installed without an error, which is a good sign. We could do a quick release for this, but we would like to add the Nomad Web 1.0.8 SHA to the recognized installer list (this is separate from the SHA-version mapping that we'll discuss separately).

piotrzarzycki21 commented 1 year ago

This task is going to be continued as part of upgrade to newest demo-tasks -> https://github.com/Moonshine-IDE/Super.Human.Installer/issues/77