3:10 p.m.
On Tue, Feb 27, 2018 at 6:43 PM, Jason Greene <jason.greene(a)redhat.com>
wrote:
On Feb 22, 2018, at 4:41 PM, Alexey Loubyansky <
alexey.loubyansky(a)redhat.com> wrote:
I could provide a default GAV coordinate resolver based on how we are
used to define our GAVs and also let the user (project owner) provide a
custom one.
Ideally the specification approach we decide on is consistent across the
family and even the universe. It’s easier IMO to look at this from a user
interaction perspective, and to consider which source of info is
authoritative.
For initial consumption there is two ways a user will specify what they
initially want:
A) Give me the latest WildFly (latest on a given branch:classifer)
B) Give me exactly this version of WildFly (e.g. WildFly 12.0.0.Final)
As you mentioned earlier in the thread, even when A is used we need to
store B so that the prov config is reproducible. Whats also interesting is
that in most cases the user does not care what the policy details are for
updating to the latest, they will happily accept the default, and really in
that scenario the authoritative source is a registry artifact in the maven
repo, not necessarily whats in the provisioning file. The policy details
also aren’t important for reproducibility, since the full version already
gives you what you need. Where it would be important in the provisioning
file is when the user has overridden the rules. As an example, just because
a user installs 12.0.0.Beta1, doesn’t mean that from now on they always
want betas. They might just want to try a particular beta, and then update
back to the main stream. So to resolve the ambiguity, in any case other
than the default, the user would have to specify the stream they are
interested in.
What I want to achieve with this is make the initial choice of A) or B) not
important in a sense that if the user chose to install the latest version,
the provisioned installation will remain 100% reprodicible since the
recorded state will include specific versions of the installed
feature-packs.
And if the user choice B), i.e. to provision a specific version, then the
usual update command would still work, because the family:branch:stream is
a part of the coordinates of the initially chosen specific version.
The same applies to the dependencies of the explicitly installed
feature-packs. The dependencies will always be of specific versions to
guarantee the reproducibility of the release. But from their coordinates we
can figure out the branch and the stream they originate from. And when
executing update we can poll for dependency updates as well.
The user would be able to switch to a different stream of the same branch,
that would have to be an explicit instruction though. I think the default
stream should be final releases. If the user wants something else then it
will need to be expressed explicitly.
Switching between branches of the same family could work too. I guess that
would depend on a specific project and the compatibility between major
version releases.
One other thing to keep in mind, from a usability perspective, is to
be
careful with using things that look like GAVs but aren’t GAVs
That's a good one, agreed.
Thanks,
Alexey
-Jason