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 <[email protected]> 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 <[email protected]> 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
