[13:29:27] btullis: as the creator of the aqs-http-gateway, what did you intend as its scope? and, has that changed, what do you think that scope should be now? [13:29:49] it allows setup of connectivity to cassandra, druid, and the data-gateway [13:30:13] and I came up with usage as this: [13:30:30] https://www.irccloud.com/pastebin/vo6gdxfs/ [13:31:29] so two services connect to druid, and all but one connect to cassandra (both that connect to druid also connect to cassandra) [13:32:24] they share a convention for a few other config params (log_level, for example). [13:33:34] but it the "mostly cassandra, sometimes druid, and one data-gateway" chart seems like a weird set [13:36:28] "Variously AQS-related" seems a closer description, but I'm considering reuse for something that is something entirely not-AQS [18:44:37] urandom: Apologies for the delay. At the time I wrote it, the data-gateway wasn't a thing. Or if it was, I didn't know about it. So I only know that it had to have the option of connecting to druid *or* cassandra. I don't think that any of the AQS services was even connecting to both, at the time. [18:46:36] I do not have strong feelings around this. All of the aqs services were moved under the ownership of a new team called 'Data Products', but that no longer exists, so I think that Data Engineering is the team most responsible for these services and the chart that runs them. [18:46:44] btullis: interesting, the druid-using examples above are at least configured as if they are using cassandra [18:46:52] they have tables associated with them, etc [18:47:43] This might have been something to do with a change around Year-in-Review, where new per-user metrics were added to some data sets, but I was only barely aware of these changes. [18:48:30] Arguably, I should keep myself better informed, but it's difficult to keep track of everything. [18:48:46] everything in this set has a number of common settings, `service_name`, `log_level`, `listen_address`, `listen_port`, etc [18:48:54] i think just by convention [18:49:01] and most connect to cassandra [18:49:06] and some druid [18:49:24] and one data-gateway, but there will be more, that's the new way of implementing aqs or aqs-like services [18:50:08] so my question(s): does this set make sense for the scope of one chart, and if so, what is a good name? [18:50:32] because the "aqs" part is misleading at this stage [18:50:45] any drive-by opinions? [18:50:46] :) [18:51:44] we started with a druid & cassandra chart and merged them [18:51:58] so I guess the outlier, if it is, is the data-gateway-using service [18:52:20] which is funny because it also uses this chart, and it *does* provide cassandra access....indirectly [18:52:35] and by "funny" I do mean "exhausting" [18:55:45] No opinions really, sorry. I'm claiming not to own it, so I would point you back to Data Engineering. It was worked on in May 2024 under this: T366157 [18:56:50] I worked on it in March 2024 under this: T360531 - OK this mentions adding support for *both* druid and cassandra to the existing aqs-http-gateway chart. [18:57:17] I still maintain that I had no knowledge of the data-gateway at the time. [18:58:57] If you think that renaming the chart to remove any reference to 'aqs' so that it can be reused more widely, that seems fine to me. I just don't consider myself an authority on it at the moment. [19:00:31] I didn't think you would be, I was fishing for some... perspective ;) [19:00:47] it's clearly changed hands a few times