Prospero update operation to a specific version

[pedro-hos]

Issue: #705

[jmesnil]

Could you also add a link to #577 please?

[jmesnil]

I'm not sure about the format. In the simple case (only 1 manifest was used to provision the installation), only the version from the manifest's Maven GAV coordinates needs to be specified.
For more complex cases (multiple manifests were used), the full Maven coordinates would needs to be specified for the manifest(s) to update to.

--version could be either <version> or a comma-separated lists of <groupId>:<artifactId>:<version>.

wdyt?

[pedro-hos]

Hi @jmesnil in that case, I think that the Bartek idea was use the name of the channel from the server configuration. Looking at the video recorded by him: https://asciinema.org/a/WMBleBkPDTLRyljlaavKkpptg it seems that the --version <CHANNEL_NAME>::<VERSION> is something like:

$ ./prospero update perform --dir wfly --version wildfly:36.0.0.Beta1

Do you think that we could use something different of <CHANNEL_NAME>::<VERSION> in the second case when there's multiple manifests? In case of have only one manifest, I thing we could drop the <CHANNEL> and provide only the <VERSION>.

[TomasHofman]

Following two points are relevant for this discussion (reference via channel name or via manifest coordinate):

• If a server is subscribed to multiple channels, the customer has to provide versions of all the involved manifests.

This point is actually not a problem, as I'm checking that the wildfly-channel lib doesn't allow to initialize a session with multiple channels that have identical manifest. That means that manifest coordinate also uniquely represents a channel. So we could use both - channel name or manifest coordinate.

• If the channel uses a URL manifest, the user should be able to provide the URL of the new manifest. Note, providing a version for a URL-based channel should be considered an error.

Here the manifest coordinate I think becomes bit problematic. We need to identify a channel we want to change, and at the same time provide a new manifest URL.

With channel name it could be as Bartek suggested --version channel-0::https:/....

With manifest coordinates, it would have to be something like --version oldurl::newurl? Single colon doesn't look like sufficient delimiter.

[TomasHofman]

The second point (changing manifest URL) is in fact in the nice-to-have section.

[pedro-hos]

I agree, w/ the name seems the correct way to make it work. Like you said: --version channel-0::https:/.... With manifest coordinates I don't see other way as --version oldurl::newurl

Should I add those examples on each bullet point? I think that it could be useful.

[jmesnil]

could you elaborate please?

[pedro-hos]

The first one is related to multiple channels. I don't know if you agree, but the ideia is not verify the compatibility of the versions present on --version parameter when using multiple channels.

TBH I didn't understand the second as well. I don't know what Bartosz was thinking on this section. Do you think that we can remove it @jmesnil?

[TomasHofman]

I think the second point is about not changing the internal provisioning config of the installation (.installation/installer-channels.yaml), which normally looks something like:

---
schemaVersion: "2.0.0"
name: "channel-0"
repositories:
  - id: "central"
    url: "https://..."
manifest:
  maven:
    groupId: "org.wildfly.channels"
    artifactId: "wildlfy"
resolve-if-no-stream: "none"

It says essentially that when you run update --version 35.0.1, the 35.0.1 version is not added internally into that subscribed channel configuration. So, the installation doesn't get locked on 35.0.1 and subsequently running update without the --version parameter would result in updating to the latest available version based on what's in the Central maven repo.

[TomasHofman]

It looks reasonable behavior to me, I wouldn't remove it. :)

[pedro-hos]

good, I got it and agree with keep this

[jmesnil]

is that different from the update list-versions operation you suggest in the nice-to-have requirements?

[pedro-hos]

That's the same from ==== Nice-to-have requirements:. I guess that we can use only one. wdyt?

[TomasHofman]

If that's from Bartek's proposal, I think he may have referred to two different operations.

• update list-versions is new operation that would list available manifest versions,
• update list is an existing operation that displays all the artifact upgrades that the upgrade operation is gonna perform (which would now need to support the --version parameter as well I guess - that we should spell out too).

I read this as Bartek suggested possibly extending the update list to as well show some info on available manifests, but that to me looks like bit too much.

Let's clarify if you have something different in mind...

[pedro-hos]

yes, it was from Bartek's proposal.

[TomasHofman]

What isn't spelled out is what happens if I try to set URL to a GAV-based manifest, but I assume that should be forbidden.

[TomasHofman]

Note that allowing the logical version would probably mean downloading all versions of manifest files form maven to be able to create mapping between logical versions and real maven versions. I kinda see that as problematic.

We would also need to be able to distinguish if given string is a logical or a real maven version, which I'm not sure if can be done reliably.

For URL based manifest it can't be used at all IMO.

(The logical version is a metadata field inside the manifest YAML, see https://download.eng.brq.redhat.com/brewroot/repos/jb-eap-8.1-maven-build/latest/maven/org/jboss/eap/channels/eap-8.1/1.0.0.GA-redhat-00012/eap-8.1-1.0.0.GA-redhat-00012-manifest.yaml)

[TomasHofman]

Modifying this point a bit, I would suggest the logical version would not be accepted as input for the --version parameter, but would be displayed next to maven version by the update list-versions command. WDYT?

(That would still require to download all the manifest file versions from Maven repo.)

[TomasHofman]

@jmesnil as I'm looking at wildfly/prospero#754 / #705 linked as related to this proposal, this proposal doesn't in fact enable that. Am I right and is that OK?

In this proposal the --version parameter only affects single invocation of given update command. The #705 requires permanent change of the manifest version in .installation/installer-channels.yaml.

[jmesnil]

@TomasHofman That seems right, #705 proposal actually correspond to the non-requirement ("Fixing" a server to a manifest version) from this #749 proposal.