one Artemis operator for multiple kube namespaces

[Thai Le <ln...@gmail.com>]

Hello,

I have a use case in which I have multiple kubernetes namespaces (DEV,
STAGING, UAT, PROD,...); each needs a cluster of multiple instances of
Artemis brokers. I follow the Artemis operator installation guide but I
have to deploy the one operator alongs with service account, role role
binding for each namespace. Since the CRD (artemis, artemisaddress,
artemisscaledown, artemissecurity) are installed at global level (not to
any namespace) why can't I have a single operator for all namespaces ?

Also, is there a prebuilt helm chart for installing the operator?

Regards

Thai Le

-- 
Where there is will, there is a way

Re: one Artemis operator for multiple kube namespaces

[Thai Le <ln...@gmail.com>]

Tim, thank you for the thoughtful explanation.

I agree with you on the 2nd point that's why i asked for the helm chart
because if a system is designed to be installed at a more-granular layer
then it should be deployed as a single unit. Anyway, i posted my question
as a feature request in the github of artemiscloud.

Thai Le

On Wed, Aug 25, 2021 at 12:31 AM Tim Bain <tb...@alumni.duke.edu> wrote:

> Same as I said in the email I just wrote, the lack of a response to any of
> these Kubernetes questions from anyone but me has me convinced that the
> authors of Artemis Cloud aren't on this list (or aren't monitoring it
> closely), so you probably won't get a good answer here to some of your
> questions such as the pre-built Helm chart.
>
> I haven't done enough with CRDs to speak authoritatively to whether it's
> possible to make one that defines multiple copies of the Artemis resources
> across multiple namespaces. My gut says that it would be possible, but
> there might be a reason it's impossible that I just don't recognize.
> However, just because you can do something doesn't mean you should, and I
> see three significant reasons why you really might not want to do this.
>
> First, I suspect you're going to end up duplicating a bunch of code due to
> needing to define each resource in each copy within the CRD, which makes
> this more complicated to maintain. As I said, I don't know CRDs deeply so
> maybe that's not accurate, but it's at least a possibility that would make
> me avoid this approach if it really would involve that kind of code reuse.
>
> Second, I believe that the best way to architect a system that will need to
> run in multiple deployment environments is to define a single copy of the
> system as the more-granular layer, and then consider whether to define an
> outer layer that defines the various copies and their various deployment
> locations. Artemis cloud itself is likely not your full system, and having
> a CRD for the multiple copies of Artemis Cloud and then other deployment
> descriptors for the other parts of the system feels likely to result in a
> lot of duplication of effort as you define repeatedly the different copies
> of the system and where they live. I think you're better off specifying
> your multiple copies (DEV, STAGING, etc.) of the entire system, rather than
> defining the copies of individual sub-parts of the system.
>
> Third, often people want different configurations (size or compute power,
> for example) for different copies of their system, and I think you're going
> to have an easier time managing those configurations if you have a single
> general definition of what the system is and then you wire in the specifics
> (size, K8s namespace, etc.) for each configuration than if you define a
> single CRD/operator that includes all of those things for all possible
> configurations. This is partly a mash-up of the first two ideas (avoiding
> code duplication plus defining the full system before defining copies), so
> maybe this is just an illustration of why the first two matter, or maybe
> it's a standalone point after all. Either way, to me it's a strong argument
> for why I wouldn't do what I think you're proposing here, even if you
> determine that it's possible.
>
> But we're pretty far afield from Artemis itself at this point, so I'll
> leave it there. And ultimately you and the rest of your team will need to
> make and then live with these decisions, so my opinions aren't the relevant
> ones, yours are.
>
> Best,
> Tim
>
> On Tue, Aug 24, 2021 at 2:10 PM Thai Le <ln...@gmail.com> wrote:
>
> > Hello,
> >
> > I have a use case in which I have multiple kubernetes namespaces (DEV,
> > STAGING, UAT, PROD,...); each needs a cluster of multiple instances of
> > Artemis brokers. I follow the Artemis operator installation guide but I
> > have to deploy the one operator alongs with service account, role role
> > binding for each namespace. Since the CRD (artemis, artemisaddress,
> > artemisscaledown, artemissecurity) are installed at global level (not to
> > any namespace) why can't I have a single operator for all namespaces ?
> >
> > Also, is there a prebuilt helm chart for installing the operator?
> >
> > Regards
> >
> > Thai Le
> >
> > --
> > Where there is will, there is a way
> >
>


-- 
Where there is will, there is a way

Re: one Artemis operator for multiple kube namespaces

[Tim Bain <tb...@alumni.duke.edu>]

Same as I said in the email I just wrote, the lack of a response to any of
these Kubernetes questions from anyone but me has me convinced that the
authors of Artemis Cloud aren't on this list (or aren't monitoring it
closely), so you probably won't get a good answer here to some of your
questions such as the pre-built Helm chart.

I haven't done enough with CRDs to speak authoritatively to whether it's
possible to make one that defines multiple copies of the Artemis resources
across multiple namespaces. My gut says that it would be possible, but
there might be a reason it's impossible that I just don't recognize.
However, just because you can do something doesn't mean you should, and I
see three significant reasons why you really might not want to do this.

First, I suspect you're going to end up duplicating a bunch of code due to
needing to define each resource in each copy within the CRD, which makes
this more complicated to maintain. As I said, I don't know CRDs deeply so
maybe that's not accurate, but it's at least a possibility that would make
me avoid this approach if it really would involve that kind of code reuse.

Second, I believe that the best way to architect a system that will need to
run in multiple deployment environments is to define a single copy of the
system as the more-granular layer, and then consider whether to define an
outer layer that defines the various copies and their various deployment
locations. Artemis cloud itself is likely not your full system, and having
a CRD for the multiple copies of Artemis Cloud and then other deployment
descriptors for the other parts of the system feels likely to result in a
lot of duplication of effort as you define repeatedly the different copies
of the system and where they live. I think you're better off specifying
your multiple copies (DEV, STAGING, etc.) of the entire system, rather than
defining the copies of individual sub-parts of the system.

Third, often people want different configurations (size or compute power,
for example) for different copies of their system, and I think you're going
to have an easier time managing those configurations if you have a single
general definition of what the system is and then you wire in the specifics
(size, K8s namespace, etc.) for each configuration than if you define a
single CRD/operator that includes all of those things for all possible
configurations. This is partly a mash-up of the first two ideas (avoiding
code duplication plus defining the full system before defining copies), so
maybe this is just an illustration of why the first two matter, or maybe
it's a standalone point after all. Either way, to me it's a strong argument
for why I wouldn't do what I think you're proposing here, even if you
determine that it's possible.

But we're pretty far afield from Artemis itself at this point, so I'll
leave it there. And ultimately you and the rest of your team will need to
make and then live with these decisions, so my opinions aren't the relevant
ones, yours are.

Best,
Tim

On Tue, Aug 24, 2021 at 2:10 PM Thai Le <ln...@gmail.com> wrote:

> Hello,
>
> I have a use case in which I have multiple kubernetes namespaces (DEV,
> STAGING, UAT, PROD,...); each needs a cluster of multiple instances of
> Artemis brokers. I follow the Artemis operator installation guide but I
> have to deploy the one operator alongs with service account, role role
> binding for each namespace. Since the CRD (artemis, artemisaddress,
> artemisscaledown, artemissecurity) are installed at global level (not to
> any namespace) why can't I have a single operator for all namespaces ?
>
> Also, is there a prebuilt helm chart for installing the operator?
>
> Regards
>
> Thai Le
>
> --
> Where there is will, there is a way
>