Wildfly cloud operator

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Wildfly cloud operator

Marek Marusic
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?


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

[hidden email]   


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Wildfly cloud operator

Ken Wills-2
Hi Marek,

On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic <[hidden email]> 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
 


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

[hidden email]   

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Wildfly cloud operator

Ondra Chaloupka
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


On Thu, Nov 8, 2018 at 4:03 PM Ken Wills <[hidden email]> wrote:
Hi Marek,

On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic <[hidden email]> 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
 


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

[hidden email]   

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Wildfly cloud operator

Tom Jenkinson
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 <[hidden email]> 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


On Thu, Nov 8, 2018 at 4:03 PM Ken Wills <[hidden email]> wrote:
Hi Marek,

On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic <[hidden email]> 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
 


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

[hidden email]   

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Wildfly cloud operator

Brian Stansberry
Sorry for neglecting to reply to this thread.

At some point I'd like to do a WildFly operator, but TBH I'm not sure when we'll get to it.

On Wed, Nov 14, 2018 at 11:28 AM Tom Jenkinson <[hidden email]> wrote:
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 <[hidden email]> 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


On Thu, Nov 8, 2018 at 4:03 PM Ken Wills <[hidden email]> wrote:
Hi Marek,

On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic <[hidden email]> 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
 


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

[hidden email]   

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Wildfly cloud operator

Miroslav Novak
In reply to this post by Tom Jenkinson
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" <[hidden email]>
> To: "Ondra Chaloupka" <[hidden email]>
> Cc: "WildFly Dev" <[hidden email]>
> 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 < [hidden email] > 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/handler.go#L37
> [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 < [hidden email] > wrote:
>
>
>
> Hi Marek,
>
> On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic < [hidden email] > 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
>
> [hidden email]
> TRIED. TESTED. TRUSTED.
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Wildfly cloud operator

Ondra Chaloupka
What I can see the wildfly-operator does not handle that either.

On Thu, Nov 15, 2018 at 9:05 AM Miroslav Novak <[hidden email]> wrote:
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" <[hidden email]>
> To: "Ondra Chaloupka" <[hidden email]>
> Cc: "WildFly Dev" <[hidden email]>
> 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 < [hidden email] > 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/handler.go#L37
> [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 < [hidden email] > wrote:
>
>
>
> Hi Marek,
>
> On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic < [hidden email] > 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
>
> [hidden email]
> TRIED. TESTED. TRUSTED.
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev