Hi Marek, On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic <mmarusic(a)redhat.com&gt; wrote: > Hello Everyone, > > The operator-framework [1] allows to create various operators for cloud. > There is already wildfly-operator > <https://github.com/banzaicloud/wildfly-operator> [1] created with > operator-framework [2]. > Does this operator cover all needed scenarios needed for cloud or are > there any plans to create official Wildfly operator? > Thanks for linking this, I hadn't seen it. There is a fair amount of other configuration support that could be provided via operator vs what I see here, but its a good example. (Basically anything you might want to change in the configuration, and I'd tend towards using the CLI vs manipulating the XML directly.) Ken > > [1] https://github.com/operator-framework/operator-sdk > [2] https://github.com/banzaicloud/wildfly-operator > > Thank you and wish you a wonderful day, > Marek > > Marek Marusic > > Associate Software Engineer - JBOSS SET TEAM > > Red Hat > > <https://www.redhat.com/> > > Purkyňova 111, 612 00 Brno > > mmarusic(a)redhat.com > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

It would also miss the highlighting general lack of EJB remoting and JTS support for transaction propagation. I guess there are other restrictions and guidance for WFLY that might exist. On 14 November 2018 at 16:00, Ondra Chaloupka <ochaloup(a)redhat.com&gt; wrote: > Hi, > > First I have to admit I don't have first hand experience with operators > but I would like to add my point of view here. > > The readme says it's an operator which provides way to startup WildFly > server in k8s clustered with kubeping protocol and creating an ingress > resource to allow inbound connection from outside world[1]. It let you > define your standalone.xml to start with and define deployment to run in > the container. The code talks the same[2]. The creator of the operator is a > company[3] providing cloud based solution so I expect they take what is the > best suiting for the customers - aka. creating a java web application and > deploy it easily to WildFly on k8s. > > As I participate on the WildFly transaction integration for OpenShift[2] > I would like highlight that the operator miss for example the logic for > handling reliable transaction recovery[4]. And other settings that is > offered by cct_modules[5]. > > Ondra > > [1] https://github.com/banzaicloud/wildfly-operator/blob/master/README.md > [2] > https://github.com/banzaicloud/wildfly-operator/blob/master/pkg/stub/hand... > [3] https://banzaicloud.com/ > [4] https://issues.jboss.org/browse/CLOUD-2261 > [5] https://github.com/jboss-openshift/cct_module > > On Thu, Nov 8, 2018 at 4:03 PM Ken Wills <kwills(a)redhat.com&gt; wrote: > >> Hi Marek, >> >> On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic <mmarusic(a)redhat.com&gt; >> wrote: >> >>> Hello Everyone, >>> >>> The operator-framework [1] allows to create various operators for cloud. >>> There is already wildfly-operator >>> <https://github.com/banzaicloud/wildfly-operator> [1] created with >>> operator-framework [2]. >>> Does this operator cover all needed scenarios needed for cloud or are >>> there any plans to create official Wildfly operator? >>> >> >> Thanks for linking this, I hadn't seen it. There is a fair amount of >> other configuration support that could be provided via operator vs what I >> see here, but its a good example. (Basically anything you might want to >> change in the configuration, and I'd tend towards using the CLI vs >> manipulating the XML directly.) >> >> Ken >> >> >>> >>> [1] https://github.com/operator-framework/operator-sdk >>> [2] https://github.com/banzaicloud/wildfly-operator >>> >>> Thank you and wish you a wonderful day, >>> Marek >>> >>> Marek Marusic >>> >>> Associate Software Engineer - JBOSS SET TEAM >>> >>> Red Hat >>> >>> <https://www.redhat.com/> >>> >>> Purkyňova 111, 612 00 Brno >>> <https://maps.google.com/?q=Purky%C5%88ova+111,+612+00+Brno&entry=gmai... >>> >>> mmarusic(a)redhat.com >>> <https://red.ht/sig> >>> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Adding messaging pov: Basically the same problem as for transactions needs to be solved for Artemis. Artemis has its own journal where unfinished transactions needs to be recovered in case that Pod with WF crashes. Another issue is scale down. If Pod with WF/Artemis is scale down then operator must move messages to other WF/Artemis cluster nodes. Is wildlfy-operator handling those problems? Thanks, Mirek ----- Original Message ----- > From: "Tom Jenkinson" <tom.jenkinson(a)redhat.com&gt; > To: "Ondra Chaloupka" <ochaloup(a)redhat.com&gt; > Cc: "WildFly Dev" <wildfly-dev(a)lists.jboss.org&gt; > Sent: Wednesday, 14 November, 2018 5:51:50 PM > Subject: Re: [wildfly-dev] Wildfly cloud operator > > It would also miss the highlighting general lack of EJB remoting and JTS > support for transaction propagation. > > I guess there are other restrictions and guidance for WFLY that might exist. > > On 14 November 2018 at 16:00, Ondra Chaloupka < ochaloup(a)redhat.com > wrote: > > > > Hi, > > First I have to admit I don't have first hand experience with operators but I > would like to add my point of view here. > > The readme says it's an operator which provides way to startup WildFly server > in k8s clustered with kubeping protocol and creating an ingress resource to > allow inbound connection from outside world[1]. It let you define your > standalone.xml to start with and define deployment to run in the container. > The code talks the same[2]. The creator of the operator is a company[3] > providing cloud based solution so I expect they take what is the best > suiting for the customers - aka. creating a java web application and deploy > it easily to WildFly on k8s. > > As I participate on the WildFly transaction integration for OpenShift[2] I > would like highlight that the operator miss for example the logic for > handling reliable transaction recovery[4]. And other settings that is > offered by cct_modules[5]. > > Ondra > > [1] https://github.com/banzaicloud/wildfly-operator/blob/master/README.md > [2] > https://github.com/banzaicloud/wildfly-operator/blob/master/pkg/stub/hand... > [3] https://banzaicloud.com/ > [4] https://issues.jboss.org/browse/CLOUD-2261 > [5] https://github.com/jboss-openshift/cct_module > > On Thu, Nov 8, 2018 at 4:03 PM Ken Wills < kwills(a)redhat.com > wrote: > > > > Hi Marek, > > On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic < mmarusic(a)redhat.com > wrote: > > > > Hello Everyone, > > The operator-framework [1] allows to create various operators for cloud. > There is already wildfly-operator [1] created with operator-framework [2]. > Does this operator cover all needed scenarios needed for cloud or are there > any plans to create official Wildfly operator? > > Thanks for linking this, I hadn't seen it. There is a fair amount of other > configuration support that could be provided via operator vs what I see > here, but its a good example. (Basically anything you might want to change > in the configuration, and I'd tend towards using the CLI vs manipulating the > XML directly.) > > Ken > > > > > [1] https://github.com/operator-framework/operator-sdk > [2] https://github.com/banzaicloud/wildfly-operator > > Thank you and wish you a wonderful day, > Marek > > > > Marek Marusic > > Associate Software Engineer - JBOSS SET TEAM > > > Red Hat > > > > Purkyňova 111, 612 00 Brno > > mmarusic(a)redhat.com > TRIED. TESTED. TRUSTED. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev