Open NottyCode opened 12 months ago
https://github.com/OpenLiberty/open-liberty/compare/integration...jhanders34:versionless-features-prototype contains the prototype code that I referenced in our call today. It shows a versionless feature for the persistence / jpa features in Jakarta / Java EE.
Some points from the call today based off of this prototype:
jakartaPlatform
public feature instead of jakartaeePlatform
. The reason for this is that io.openliberty.jakartaeePlatform
features already exist. They are private features. They would need to be renamed if we wanted to use jakartaeePlatform
instead. I actually like jakartaPlatform
since it is shorter. If you chose to use jakartaeePlatform
, just renaming the existing one to add internal
to the feature name.unversioned.persistence-2.0
in the tolerates list, but I did not create that feature. It would exist in the WebSphere Liberty repo.javaeePlatform
for 7.0 and 6.0 feature.io.openliberty.jakartaPlatform.internal
to io.openliberty.jeePlatform.internal
. Then it easily covers both javaee and jakartaee.jakartaPlatform
feature, the prototype will not have a preferred version that starts up an actual feature. In the end if jakartaPlatform
, javaeePlatform
or mpPlatform
feature isn't specified the server should fail to start.WLP-Required-Feature: jakartaPlatform, javaeePlatform, mpPlatform
in the persistence public feature is just an example of a property that could be in unversioned features to tell the FeatureManager that a required feature is needed for this feature and to fail if it isn't specified. For mp features, it would just list mpPlatform.persistence
feature will be enabled and the persistence-x.y
would also be enabled. If the persistence
feature was a singleton, a conflict would be triggered. SymbolicNameTest.testSingleton will need to be updated to handle versionless features not being singletons.persistence
and jpa-x.y
/ persistence-x.y
are both listed in the started features. There could be a change in the FeatureManager to remove the unversioned feature (persistence
) if we so chose.mpPlatform-x.y
features will have a feature dependency on the appropriate jakartaPlatform.internal
/ jeePlatform.internal
feature.jpa
. I would recommend not and update the persistence
feature to have an attribute of WLP-AlsoKnownAs: jpa
.jakartaPlatform
/ javaeePlatform
. We could special case that in the repository logic that is used for feature installation. Something to probably discuss with Andrew Rouse. If we used auto features, then that wouldn't be a problem I believe.jakartaPlatform
/ javaeePlatform
would be listed in the server.xml which would bring in the jeePlatform.internal
feature and that is what is referenced in the tolerated unversioned
features so we can easily identify which of the chains matches the list of specified features and not need to test each chain when doing toleration. Only when we can't identify a specific chain based off of the list of features provided would we need to do some toleration permutations.internal
should probably be added to the unversioned.persistence
feature name. I chose to have unversioned
in the name right after io.openliberty
to easily be able to identify all of the unversioned private features because they will all be together.eeCompatible
features depend on the appropriate jeePlatform.internal
feature, but as I stated in the call I don't think this is the right thing to do.I created a draft PR https://github.com/OpenLiberty/open-liberty/pull/26301 showcasing Jared's changes as well as unversioned servlet
UFO review (part 1) notes:
Slide 4
Slide 6
Slide 9
Slide 12
Slide 13
<platform>
or <featurePlatform>
element instead of re-using <feature>
Slide 17
Slide 18
Slide 20
Re: slide 13:
Perhaps create a <platform> or <featurePlatform> element instead of re-using <feature>
I think it should be considered to add an attribute on featureManager as an alternative..
E.g. <featureManager jakartaPlatform="9.1" microprofilePlatform="5.0">
.
The fact that there should only be one of each of these can be captured more efficiently by the basic rules for XML without having to be performed by Liberty-specific validation.
UFO review (part 2) notes:
Slide 4:
Slide 23:
Slide 36:
@tbitonti and I were chatting in the halls of the RTP lab today. As identified in the POC Forum, there is a possibility of multiple possibilities for non-versioned features and that the server start will fail in that situation. The user can avoid this situation by using environment variable(s) that give the preferred list of versioned features to be used when 1) there are multiple possible potential choices for non-versioned features, and 2) the specific versioned features specified don't narrow the choice to a specific version.
I don't have issues with this concept, but do have some requests for the developer experience and use experience that will allow the user to avoid waiting on the server start to discover the error condition. I'll record these here and tag some folks in hopes they'll be able to add details/ideas, or map these to requirements.
1) I think there should be something available in the developer tools (i.e. with auto-completion) that helps the user know that they've set up this condition. Tom was suggesting, as well, that the developer tools could even suggest that the user either set a specific feature level, or set up the environment variable list. @cherylking @scottkurz
2) It would be nice to have some sort of validation, in general, in support of discovering this condition prior to server start. I don't know if that should be a part of the existing set of script. @NottyCode
UFO review notes (part 3)
Slide 3
Slide 17
Slide 18
PREFERRED_FEATURE_VERSION
setting for cross platform versionless features (e.g. servlet-5.0, mpHealth). Conclusion: must either specify the platform selector or use PREFERRED_FEATURE_VERSION
to break current and possible future ambiguity when versionless features cross a platform boundary. Otherwise we risk breaking zero migration.Slide 25
Slide 49 for InstantOn: There is an InstantOn concern around the use of env values to configure the feature manager with PREFERRED_FEATURE_VERSIONS. The Semeru runtime returns null for most all environment variables except ones specified with WLP_IMMUTABLE_VARS
before checkpoint
https://github.com/OpenLiberty/open-liberty/blob/e2e768871ba4095a2ed128c6e05807f8354d3425/dev/com.ibm.ws.kernel.boot.ws-server/publish/bin/server#L95
My initial thought is we will want to add WLP_IMMUTABLE_VARS to the list of defaults so users do not have to set it themselves. That is done at https://github.com/OpenLiberty/open-liberty/blob/e2e768871ba4095a2ed128c6e05807f8354d3425/dev/com.ibm.ws.kernel.boot.ws-server/publish/bin/server#L905-L906
UFO review notes (part 4)
Slide 19
Slide 26
Slide 36
Slide 27
Slide 31
Slide 37
Slide 42
Slide 43
<platform/>
elementSlide 46
Slide 48
General comment:
All comments from above have been resolved and changed in the UFO document: https://ibm.ent.box.com/file/1484909310089?s=5fk61j0mfbw4que6jgmmw3vizg3lb6qn
Beta BLOG issue is #28656
Description
While the Liberty feature design allows many great features like zero migration and us to support multiple EE versions it does make some things harder. For example if you are not using one of the convenience features and you want to be able to easily move from one EE/MP version to another you have to work out the right combination of new feature versions to specify them.
Proposed is an alternative option. We would allow unversioned EE features to be specified, but in combination another feature must be provided to indicate the platform version required. If no platform versioning feature is provided then there would be a startup failure to ensure we don't end up with zero migration breaks. An example of what this might look like is:
or
As the number of features required grows the value of this increases. It also makes it simpler for operations teams to augment developer provided configurations. For example when deploying into kube you might wish to have a health check capability inserted when a container image is built, but it isn't required by the application. This would enable the right mpHealth to be injected at container build time without needing to worry about what version of Jakarta EE/MicroProfile was used by the developer.
Documents
When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.
Aha: Externally raised RFE (Aha)
UFO: Link to Upcoming Feature Overview document
FTS: Link to Feature Test Summary GH Issue
Beta Blog: Link to Beta Blog Post GH Issue
GA Blog: Link to GA Blog Post GH Issue
Process Overview
Prioritization
Design
Implementation
Legal and Translation
Beta
GA
Other Deliverables
General Instructions
The process steps occur roughly in the order as presented. Process steps occasionally overlap.
Each process step has a number of tasks which must be completed or must be marked as not applicable ("N/A").
Unless otherwise indicated, the tasks are the responsibility of the Feature Owner or a Delegate of the Feature Owner.
If you need assistance, reach out to the OpenLiberty/release-architect.
Important: Labels are used to trigger particular steps and must be added as indicated.
Prioritization (Complete Before Development Starts)
The (OpenLiberty/chief-architect) and area leads are responsible for prioritizing the features and determining which features are being actively worked on.
Prioritization
[ ] Feature added to the "New" column of the Open Liberty project board
[ ] Priority assigned
Design (Complete Before Development Starts)
Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID.
Design Preliminaries
ID Required
, if non-trivial documentation needs to be created by the ID team.ID Required - Trivial
, if no design will be performed and only trivial ID updates are needed.Design
Design Review Request
Design Approval Request
Design Approved
No Design
No Design Approval Request
No Design Approved
Product Management Approval Request
and notifies OpenLiberty/product-managementProduct Management Approved
(OpenLiberty/product-management)FAT Documentation
[ ] "Feature Test Summary" child task created
Implementation
A feature must be prioritized before any implementation work may begin to be delivered (inaccessible/no-ship). However, a design focused approach should still be applied to features, and developers should think about the feature design prior to writing and delivering any code.
Besides being prioritized, a feature must also be socialized (or No Design Approved) before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking it
kind=noship
or beta fencing it.Code may not GA until this feature has obtained the "Design Approved" or "No Design Approved" label, along with all other tasks outlined in the GA section.
Feature Development Begins
In Progress
labelLegal and Translation
In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. Both MUST be completed before Beta or GA is requested.
Legal (Complete before Feature Complete Date)
Translation (Complete 1 week before Feature Complete Date)
Innovation (Complete 1 week before Feature Complete Date)
[ ] Consider whether any aspects of the feature may be patentable. If any identified, disclosures have been submitted.
Beta
In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.
Beta Code
kind=beta
,ibm:beta
,ProductInfo.getBetaEdition()
target:beta
and the appropriatetarget:YY00X-beta
(where YY00X is the targeted beta version).release:YY00X-beta
(where YY00X is the first beta version that included the functionality).Beta Blog (Complete 1.5 weeks before beta eGA)
[ ] Beta blog issue created and populated using the Open Liberty BETA blog post template.
GA
A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.
Feature Complete
target:ga
and the appropriatetarget:YY00X
(where YY00X is the targeted GA version).Focal Point Approvals (Complete by Feature Complete Date)
These occur only after GA of this feature is requested (by adding a
target:ga
label). GA of this feature may not occur until all approvals are obtained.All Features
focalApproved:externals
@OpenLiberty/demo-approvers Demo scheduled for EOI [Iteration Number]
to this issue.focalApproved:demo
.focalApproved:fat
.focalApproved:globalization
.Design Approved Features
focalApproved:accessibility
.focalApproved:id
.focalApproved:performance
.focalApproved:sve
.focalApproved:ste
.focalApproved:svt
.Remove Beta Fencing (Complete by Feature Complete Date)
GA Blog (Complete by Feature Complete Date)
Post GA
[ ] Replace
target:YY00X
label with the appropriaterelease:YY00X
. (OpenLiberty/release-manager)Other Deliverables
[ ] Standalone Feature Blog Post A blog post specifically about your feature or N/A. (OpenLiberty/release-architect)
[ ] OL Guides OL Guides assessment is complete or N/A. (OpenLiberty/guide-assessment)
[ ] Dev Experience Developer Experience & Tools work is complete or N/A. (OpenLiberty/dev-experience-assessment)