[JBoss JIRA] (DROOLS-4515) [DMN Designer] Kogito - DMNMarshaller - Improve JsArrayLike-getter-APIs
by Guilherme Gomes (Jira)
[ https://issues.jboss.org/browse/DROOLS-4515?page=com.atlassian.jira.plugi... ]
Guilherme Gomes updated DROOLS-4515:
------------------------------------
Summary: [DMN Designer] Kogito - DMNMarshaller - Improve JsArrayLike-getter-APIs (was: [DMN Designer] Kogito - DMNMarshaller - Improve JsArrayLike-based APIs)
> [DMN Designer] Kogito - DMNMarshaller - Improve JsArrayLike-getter-APIs
> -----------------------------------------------------------------------
>
> Key: DROOLS-4515
> URL: https://issues.jboss.org/browse/DROOLS-4515
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Guilherme Gomes
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
> Attachments: json.png, stack.png
>
>
> Currently, the {{DMNMarshaller}} works following this stack:
> !stack.png|width=400!
> However the {{JSITDefinitions}} class (and all other DMN classes related to *Jsonix*) are "artificially" typed JSON objects. This objects define odd list structures, like this:
> !json.png|width=400!
> Ideally, the list of DRGElements would be a list of the entries in the *value* key, and the entries from the *name* key would be discarded.
> This JIRA comprehends to change {{JsArrayLike}}-based APIs to {{java.util.List}} APIs.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFWIP-198) Operator long-term strategy
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFWIP-198?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFWIP-198:
-----------------------------------
That is a legitimate concern.
My understanding is that Operator are designed to configure and maintain a specific product (e.g. Prometheus). In that case, the Operator must provide options for the resources that are actually required by the product.
In EAP case, this is different as the product is more open-ended since the Operator configure and maintain a user application.
We have to find a balance between exposing all Kubernetes resources/options through the operator (which would be a disaster from a usability and maintenance point of view) and preventing legitimate uses cases (eg. having the user application access a shared persistent volume)
I don't have a good answer to give you except that analysis should be done on a per feature basis.
First we need to make sure that the Operator is able to do all the things that we currently support.
Then any new features will have to be analysed to determine if there is a need to expose underlying Kubernetes options vs using the operator to encapsulate it.
> Operator long-term strategy
> ---------------------------
>
> Key: WFWIP-198
> URL: https://issues.jboss.org/browse/WFWIP-198
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Facts:
> # Operator creates and manges internaly several kubernetes objects; StatefulSet, Pod, Service, Routes. By rough estimation these kubernetes objects expose approximately 50 options[2]. Operator now expose approximately 10 options [1].
> # EAP7-1192 is currently designed in way operator is integral part of solution. You can not turn off operator to EAP7-1192 properly work.
> # User cant touch internal Kubernetes objects. Operator manages them and can overwrite changes anytime.
> So given these facts question is what is long-term strategy with Operator?
> # Operator will provide all options of internal objects. Everything I am able to configure directly with Kubernetes objects I will be able to configure with Operator
> # Operator will expose just most useful options. If user wants to make something special he has to "turn off" operator and to be on his own. (Loosing transaction support provided by EAP7-1192)
> # Operator will expose just most useful options. If user wants to make something special he can and Operator won't overwritten his changes. (I dont know if it is feasible?)
> [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#wil...
> [2]
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#pods...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#stat...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#serv...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#ingr...
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFWIP-202) Runtime changes to disableHTTPRoute are not reflected in Route object
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFWIP-202?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFWIP-202:
-----------------------------------
[~mchoma] correct (and for service as well). I'll create a fix in upstream and ping you when a EAP Operator image with it is available
> Runtime changes to disableHTTPRoute are not reflected in Route object
> ---------------------------------------------------------------------
>
> Key: WFWIP-202
> URL: https://issues.jboss.org/browse/WFWIP-202
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Any changes (adding, removing or updating) made to disableHTTPRoute attribute after WildFlyServer CR was created are not reflected in underlying Route object.
> Reproducer:
> # create CR
> {code}
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> generation: 1
> name: eap-cd
> namespace: default
> spec:
> applicationImage: >-
> brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4
> size: 1
> disableHTTPRoute: false
> {code}
> # Edit CR with disableHTTPRoute: true. I would expect Route object will be deleted.
> {code}
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> generation: 1
> name: eap-cd
> namespace: default
> spec:
> applicationImage: >-
> brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4
> size: 1
> disableHTTPRoute: true
> {code}
> # Route object eap-cd is not disabled/deleted
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (SWSQE-838) Investigate how we could use git-crypt
by Filip Brychta (Jira)
[ https://issues.jboss.org/browse/SWSQE-838?page=com.atlassian.jira.plugin.... ]
Filip Brychta commented on SWSQE-838:
-------------------------------------
Using jenkins credentials seems to be good option. Another part of this tasks is how to share credentials among team members. Currently we have private mojo page which is not very good solution. git-crypt could be solution for that. We need to check how we could use it and maybe if we could use it directly in jenkins jobs so there would be no need for credentials to be stored in jenkins master.
> Investigate how we could use git-crypt
> --------------------------------------
>
> Key: SWSQE-838
> URL: https://issues.jboss.org/browse/SWSQE-838
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Filip Brychta
> Assignee: Prachi Yadav
> Priority: Minor
> Labels: infrastructure
>
> Do we want to use git-crypt to store credentials?
> Problem is how to safely share credentials among team members, how to use them in jenkins jobs and automation, etc.
> # check how other teams are doing it
> # suggest improvements for kiali team
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (SWSQE-838) Investigate how we could use git-crypt
by praneeth bajjuri (Jira)
[ https://issues.jboss.org/browse/SWSQE-838?page=com.atlassian.jira.plugin.... ]
praneeth bajjuri commented on SWSQE-838:
----------------------------------------
we have an option in Jenkins adding global environment variables there we can add our credentials and we can use globally for any job by injecting those environment variables.
We have another option in Jenkins by creating global credentials then we can use for any job directly.
If we want to use credentials in open-shift securely there we have a concept called secrets
> Investigate how we could use git-crypt
> --------------------------------------
>
> Key: SWSQE-838
> URL: https://issues.jboss.org/browse/SWSQE-838
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Filip Brychta
> Assignee: Prachi Yadav
> Priority: Minor
> Labels: infrastructure
>
> Do we want to use git-crypt to store credentials?
> Problem is how to safely share credentials among team members, how to use them in jenkins jobs and automation, etc.
> # check how other teams are doing it
> # suggest improvements for kiali team
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months