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 <lnthai2...@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 >