-
Notifications
You must be signed in to change notification settings - Fork 466
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WFCORE-6668 Ensure read-feature-description results contain stability as reported by associated description for use by WildFly Glow #5842
Conversation
@jfdenise This should be in better shape now. |
@pferraro , I tried and I don't see what I was expecting.
I am building the feature-pack with preview as minimum, provisioning with preview. Starting the server with --stability=preview, the reported stability level for I am perhaps missing something. |
Which class did you override? |
Ah - you must have overridden the Stability of the extension. I'll need to ensure that the resource definition of the extension reflects its stability level so that the corresponding MMR.getStability() returns the expected value. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Core -> Full Integration Build 13429 outcome was FAILURE using a merge of ab5f793 |
Core -> WildFly Preview Integration Build 13253 outcome was FAILURE using a merge of ab5f793 |
Core -> Full Integration Build 13190 outcome was FAILURE using a merge of ab5f793 |
@pferraro, yes, the extension. In such a case, should all defined resources/attributes located in the extension be at least at the extension stability level? It could apply to any hierarchy, the stability, if not redefined locally, being inherited from the parent. |
Latest changes seem to have caused the feature spec generator to hang. I will nvestigate/
That said, with the above changes, the corresponding /subsystem=* resource definitions and their child resources, will all inherit the max stability of the extension that created them. Unfortunately, for objects associated with resource definitions; e.g. like AttributeDefinitions, OperationDefinitions, Notifications, etc.; cannot get the same treatment, since none of these abstractions are encapsulated by interfaces that can be reasonably decorated. |
…inition. MRR.enables(...) should very that target feature is enabled by stability level of the process. Update OperationContext.getStability() so as not to rely on MMR.getStability().
…ibute descriptions.
@jfdenise OK - this should be working now. |
I'm sorting through the test failures, but at least we are no longer hanging while generating feature specs... |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
… as reported by associated description.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
@pferraro , thank-you! I can see the stability level at the extension level and the sub resources inheriting it. |
/retest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine with me with respect to Galleon provisioning.
Core -> Full Integration Build 13223 outcome was FAILURE using a merge of 02ae8ee Failed tests
|
Core -> Full Integration Build 13224 outcome was FAILURE using a merge of 02ae8ee Failed tests
|
Core -> Full Integration Build 13225 outcome was FAILURE using a merge of 02ae8ee Failed tests
|
@pferraro / @jfdenise Are we fine treating this as a task and not as a feature request? This is going to add a new field exposing additional information and its requirement is driven by a feature request, so I ran into the doubt when I was going to merge it. Adding a hold label until it gets confirmed. |
@yersan , I would say yes, this operation is not exposed, it is there to be consumed by Galleon. |
Thanks @pferraro @jfdenise @bstansberry |
https://issues.redhat.com/browse/WFCORE-6668