Alfresco discussion and collaboration. Stick around a few hours after asking a question.
Official support for Enterprise subscribers: support.alfresco.com.
Join in the conversation by getting an IRC client and connecting to #alfresco at Freenode. Our you can use the IRC web chat.
More information about the channel is in the wiki.
More help is available in this list of resources.
2018-10-22 08:32:07 GMT *** angelborroy_ is now known as angelborroy
2018-10-22 08:58:10 GMT *** angelborroy_ is now known as angelborroy
2018-10-22 09:12:23 GMT <AFaust> QQ: I am blind - Where is the Share Docker build source located at?
2018-10-22 09:13:13 GMT <AFaust> Can't find it in the 6.0.7-ga tag of https://github.com/Alfresco/acs-community-packaging
2018-10-22 09:13:14 GMT <alfbot> Title:GitHub - Alfresco/acs-community-packaging: Packaging of Docker containers, war file and zip for Alfresco Content Services (Community) (at github.com)
2018-10-22 09:17:17 GMT <alfresco-discord> <Arun> How to attach a file from alfresco content service into alfresco process service dynamically
2018-10-22 09:19:07 GMT <AFaust> By having the user pick it via a task form file/attachment field (default use case)? Or do you mean "programmatically"?
2018-10-22 09:27:54 GMT <DarkStar1> Hola people
2018-10-22 09:28:39 GMT <alfresco-discord> <Arun> @AFaust sorry my query is, if i browse file from APS , it should only appear particular folder path to upload the file.when i click the upload ACS repository option.
2018-10-22 09:40:40 GMT <alfresco-discord> <Arun> @Francesco Corti
2018-10-22 09:47:48 GMT <AFaust> Hmm... I hadn't realised that my own, naive Content Service Repository image is already ~150 MiB smaller than the Enterprise image, and it contains ImageMagick / PDF Renderer whereas the official image only calls these per HTTP...
2018-10-22 09:48:50 GMT <AFaust> And my base OS is Ubuntu, which is supposed to be quite "fat" (if I remember some complaints correctly)
2018-10-22 09:55:41 GMT <AFaust> Ah, forget it - I forgot to count the last step in my child image(s) which adds the WAR - so actually about the same size
2018-10-22 10:46:36 GMT <AFaust> angelborroy: Since you already tried out the default Docker images, maybe you can tell me (without me having to look further and not finding anything) - How is ASS supposed to be initialised (SOLR cores created)? The CMD does not do it, neither did I find some magic in either Docker Compose nor Helm charts for it...
2018-10-22 10:48:47 GMT <angelborroy> This one?
2018-10-22 10:48:48 GMT <angelborroy> https://github.com/Alfresco/SearchServices/blob/master/packaging/src/docker/Dockerfile#L24
2018-10-22 10:48:49 GMT <alfbot> Title:SearchServices/Dockerfile at master · Alfresco/SearchServices · GitHub (at github.com)
2018-10-22 10:49:38 GMT <angelborroy> No, sorry, this one:
2018-10-22 10:49:39 GMT <angelborroy> https://github.com/Alfresco/SearchServices/blob/master/packaging/src/docker/6.x/docker-compose.yml#L46
2018-10-22 10:49:40 GMT <alfbot> Title:SearchServices/docker-compose.yml at master · Alfresco/SearchServices · GitHub (at github.com)
2018-10-22 10:52:37 GMT <AFaust> Ah, ok, in that Docker-Compose... ok, but how do the Helm charts deal with this. I did not find such a property there...
2018-10-22 10:54:40 GMT <AFaust> Grml... for some reason my WLAN is quite unstable today. And this whole minikube setup really has not been built with changing IP addresses in mind - generated certificate is hard-coded to a specific IP, so after a connection drop + reset of AP + new DHCP lease I have to try and kill + restore the Kubernetes cluster...
2018-10-22 10:58:51 GMT <angelborroy> I didn’t inspected Helm charts
2018-10-22 10:59:13 GMT <angelborroy> And I can’t find where is the link in a quick overview
2018-10-22 13:22:17 GMT <alfresco-discord> <bhagyas> AFaust aren't you supposed to use a secrets manager along with Kube?
2018-10-22 13:27:35 GMT <AFaust> "Supposed"... sure, best practices and such, but that just relates to any shared properties that you may want to keep confidential...
2018-10-22 13:27:59 GMT <AFaust> Not sure if I would like to have literally everything (i.e. SOLR config properties) stored there
2018-10-22 13:28:39 GMT <AFaust> And even so, then the Helm chart would at least contain a mapping from the secret to the Docker image env
2018-10-22 13:29:02 GMT <AFaust> (since there is no special tooling / API inside of Alfresco to dynamically lookup such secrets)
2018-10-22 14:04:11 GMT <alfresco-discord> <bhagyas> when it comes to some frameworks, best practises are the only way
2018-10-22 14:04:47 GMT <alfresco-discord> <bhagyas> i think maybe if alfresco had a zookeeper or similar based config management, might have been easier to port to kube
2018-10-22 14:05:06 GMT <alfresco-discord> <bhagyas> the current properties based one is somewhat dated for distributed config management
2018-10-22 14:05:39 GMT <alfresco-discord> <bhagyas> i wonder how the new modularisation project is dealing with the configuration management
2018-10-22 14:05:52 GMT <alfresco-discord> <bhagyas> maybe its a good time to migrate to a better way
2018-10-22 14:05:53 GMT <alfresco-discord> <bhagyas> 😃
2018-10-22 14:09:20 GMT <alfresco-discord> <bhagyas> or maybe we can create a config mapper (similar to the discussion we had about yaml a week ago)
2018-10-22 14:10:45 GMT <AxelFaust> No reason there could not be a etcd-based properties factory in Alfresco, and I believe that is all it would take to be more in line with Kubernetes
2018-10-22 14:11:07 GMT <AxelFaust> It would even be able to support subsystem config properties isolation via directories...
2018-10-22 14:11:28 GMT <AxelFaust> And dynamic config + restart of subsystems by listening to changes...
2018-10-22 14:12:30 GMT <AxelFaust> More interesting though would be the question of potential rolling restarts in case of global config changes
2018-10-22 14:14:21 GMT <alfresco-discord> <bhagyas> that's based on your kubernetes policy
2018-10-22 14:14:38 GMT <alfresco-discord> <bhagyas> for some applications, like Alfresco - a rolling deployment might not be the best option
2018-10-22 15:06:52 GMT <AFaust> I don't know how, but after 3 - 5 WLAN resets and attempts to work with minikube, that piece of junk has messed up my Windows network driver/service so bad that I have about 100-times latency / reduced throughput. Even simple web pages only loaded in chunks before I restarted Windows just now...
2018-10-22 15:15:06 GMT <alfresco-discord> <yreg> Again the M$ curse heehe
2018-10-22 15:38:41 GMT *** DragiBus_ is now known as DragiBus
2018-10-22 16:22:00 GMT <AFaust> Grml... Alfresco seriously should revise their Helm chart repository concept. Why the heck is chart version 1.0.2 for alfresco-content-services-community in stable when it refers to Alfresco 6.1.0-ea?
2018-10-22 16:22:48 GMT <angelborroy> They are version Helm chars (DBP in general), no ACS / Alfresco or old-fashioned concepts
2018-10-22 16:22:53 GMT <angelborroy> version > versioning
2018-10-22 16:24:23 GMT <AFaust> Yeah, but when you (as a "customer") are upgrading your release / deployment to a new version of a stable chart, would you expect to get some unstable EA software?
2018-10-22 16:24:47 GMT <angelborroy> nice catch
2018-10-22 16:24:57 GMT <angelborroy> I don’t think anyone is using Helm by now
2018-10-22 16:24:57 GMT <AFaust> I also found the commit that broke the whole SSL / ingress thing for me on the "latest" chart versions: https://github.com/Alfresco/acs-community-deployment/commit/40fc304f6042ea67e040ef50612e464f003ca422#diff-204758783c9e5d405302793aa61f026d
2018-10-22 16:24:58 GMT <alfbot> Title:repo-3763 :Remove force ssl · Alfresco/acs-community-deployment@40fc304 · GitHub (at github.com)
2018-10-22 16:25:03 GMT <angelborroy> But it’s something relevant, yes
2018-10-22 16:25:45 GMT <AFaust> Using the documented steps to get set up with helm really drives you against many walls as it assumes the latest version of the charts will always work...
2018-10-22 16:26:25 GMT <AFaust> Now I am explicitly going to use 1.0.0 and hoping I can finally access Repository / Share in a way that resembles "being able to work with it"
2018-10-22 16:26:54 GMT <yreg> AFaust, don't forget to raise issues
2018-10-22 16:30:37 GMT <angelborroy> I remember I patched that version in 2 or 3 points before getting it up & runnin
2018-10-22 16:30:46 GMT <AFaust> I am also quite confused by their use of the https://github.com/Alfresco/acs-community-deployment and https://github.com/Alfresco/acs-deployment projects
2018-10-22 16:30:47 GMT <alfbot> Title:GitHub - Alfresco/acs-community-deployment: Deployment descriptors pull together Alfresco Content Services (Community) (at github.com)
2018-10-22 16:30:50 GMT <angelborroy> After that I understood that Helm is far far away from beain usable
2018-10-22 16:30:57 GMT <angelborroy> beain > being
2018-10-22 16:31:26 GMT <AFaust> Only 2 tags in https://github.com/Alfresco/acs-community-deployment refer to Community, all other 4 to Enterprise
2018-10-22 16:31:27 GMT <alfbot> Title:GitHub - Alfresco/acs-community-deployment: Deployment descriptors pull together Alfresco Content Services (Community) (at github.com)
2018-10-22 16:31:28 GMT <yreg> I only experimented with that during 6.0 EA
2018-10-22 16:31:50 GMT <yreg> And my experience was rather smooth, and I didn't need to patch anything
2018-10-22 16:32:19 GMT <yreg> But I guess during that period they made sure everything is working as expected for their EA testers
2018-10-22 16:32:27 GMT <angelborroy> Did you tested it fully, yreg?
2018-10-22 16:32:37 GMT <AFaust> Probably you were lucky and you picked a time when the only published chart was the one that was working
2018-10-22 16:33:31 GMT <yreg> I followed the tutorial from GitHub and that worked out, I experimented with a few things (changes to the values ... etc) and that's all
2018-10-22 16:34:13 GMT <yreg> The only issue I noticed back then was that the store id/name was hardcoded and it wasn't automatically deleted when I undeploy charts
2018-10-22 16:34:39 GMT <yreg> And I had to lookup / execute few manual commands to be able to restart from scratch for a second spin
2018-10-22 16:35:28 GMT * AFaust is taking a few steps back so he can get sufficient speed for running up the wall...
2018-10-22 16:36:51 GMT <AFaust> Even with stable chart version 1.0.0 this whole damn thing doesn't want to play nice. Despite "nginx.ingress.kubernetes.io/ssl-redirect: false" annotation the damn ingress is still redirecting me to HTTPS despite my chart/pods having been configured to use http
2018-10-22 16:40:21 GMT <AFaust> Though at least now I don't get the SSL_RECORD_TOO_LONG error anymore. So something has changed.
2018-10-22 16:47:21 GMT <AFaust> Finally... repeated everything from the start after deleting all releases / pods, and now it actually "works"
2018-10-22 16:47:48 GMT <AFaust> Well... at least I can login to Share. Don't mind the various errors I get on my dashboard...
2018-10-22 16:47:57 GMT <yreg> hehe
2018-10-22 16:48:47 GMT <angelborroy> AFaust are you trying to convince yourself that Helm is not mature enough?
2018-10-22 16:48:58 GMT <AFaust> Ah, right... now I am running into the issue I asked angelborroy about: SOLR not being initialised...
2018-10-22 16:49:29 GMT <yreg> Seriously ?
2018-10-22 16:49:37 GMT <AFaust> angelborroy: I have no doubt that Helm itself as a tool is mature enough. Alfresco Helm charts and release process on the other hand...
2018-10-22 16:49:37 GMT <angelborroy> probably that param is missed in the parametrisation of the image
2018-10-22 16:50:03 GMT <AFaust> Yes it is... remember, you found it in the docker-compose YAML, but it is nowhere to be found in the Helm chart
2018-10-22 16:50:04 GMT <angelborroy> I meant that, yes
2018-10-22 16:50:33 GMT <yreg> I remember seeing it in one of the extracted charts
2018-10-22 16:50:44 GMT <yreg> At the time I was experimenting with the thing
2018-10-22 16:51:02 GMT <AFaust> Ok, time to test the "deploy from source" part of the guide. I mean I already had it checked out for the SSL bit anyway...
2018-10-22 16:52:13 GMT <yreg> Confirmed : SOLR_CREATE_ALFRESCO_DEFAULTS: alfresco,archive
2018-10-22 16:52:29 GMT <angelborroy> In what Helm Char, yreg?
2018-10-22 16:52:47 GMT <angelborroy> 1.0.0 / 1.0.1 / 1.0.2 / 6.1.0-ea /1.20
2018-10-22 16:52:48 GMT <angelborroy> ?
2018-10-22 16:52:57 GMT <yreg> Alfresco-search-0.0.2.tgz
2018-10-22 16:53:19 GMT <angelborroy> 0.0.2 smells to mature… Great!
2018-10-22 16:55:18 GMT <yreg> angelborroy, it is present on master as well : https://github.com/Alfresco/alfresco-search-deployment/blob/master/helm/alfresco-search/values.yaml#L40
2018-10-22 16:55:19 GMT <alfbot> Title:alfresco-search-deployment/values.yaml at master · Alfresco/alfresco-search-deployment · GitHub (at github.com)
2018-10-22 16:55:38 GMT <angelborroy> Yes, I linked that about 6 hours ago
2018-10-22 16:55:45 GMT <angelborroy> Thanks for coming it back again
2018-10-22 16:55:54 GMT <AFaust> Ahh - it is using a sub-chart for this, referring the the alfresco-search 0.0.4 in the alfresco-content-services-community 1.0.0 chart
2018-10-22 16:56:37 GMT <AFaust> angelborroy: You linked the docker-compose, not the helm chart I believe (will check history on OOTBee Discord, but am quite sure I did not see that linked)
2018-10-22 16:56:47 GMT <angelborroy> Yep
2018-10-22 16:56:49 GMT <angelborroy> my fault
2018-10-22 16:56:53 GMT <angelborroy> this is a helm chart
2018-10-22 16:58:07 GMT <angelborroy> last time there were also some mixing of quay and Docker resources
2018-10-22 16:58:15 GMT <angelborroy> What makes confusing follow up all the thing
2018-10-22 16:58:41 GMT <AFaust> I did not even know that project existed before. It is quite annoying to have to jump so many small-ish code repositories...
2018-10-22 16:59:09 GMT <AFaust> There still are some quay.io references in there from time to time, depending on where you look
2018-10-22 16:59:41 GMT <AFaust> i.e. https://github.com/Alfresco/SearchServices/blob/master/packaging/src/docker/6.x/docker-compose.yml#L37
2018-10-22 16:59:42 GMT <alfbot> Title:SearchServices/docker-compose.yml at master · Alfresco/SearchServices · GitHub (at github.com)
2018-10-22 16:59:51 GMT <yreg> In my experience, everything should be available on docker hub except for experimental new stuff that is disabled by default
2018-10-22 17:00:01 GMT <angelborroy> wrong
2018-10-22 17:00:16 GMT <angelborroy> They want to include every ACS (payed) artifact in quay.io
2018-10-22 17:00:42 GMT <AFaust> Oh great, the project https://github.com/Alfresco/alfresco-search-deployment does not contain any tags for their releases so far...
2018-10-22 17:00:43 GMT <alfbot> Title:GitHub - Alfresco/alfresco-search-deployment (at github.com)
2018-10-22 17:01:07 GMT * yreg is getting the feeling angelborroy is jumping on every opportunity to contradict ...
2018-10-22 17:01:27 GMT <angelborroy> I’m just trying to provide you infomation
2018-10-22 17:01:38 GMT <angelborroy> But I can shut up now and let you find the way yourself
2018-10-22 17:01:45 GMT <yreg> That was the initial plan angelborroy but then they did deploy those images to docker hub as well
2018-10-22 17:01:48 GMT <AFaust> Though I must agree here... the "official" (public) architecture decision document confirms what angel said: https://github.com/Alfresco/alfresco-anaxes-shipyard/blob/master/docs/adrs/0002-docker-registry-for-internal-and-protected-images.md
2018-10-22 17:01:49 GMT <alfbot> Title:alfresco-anaxes-shipyard/0002-docker-registry-for-internal-and-protected-images.md at master · Alfresco/alfresco-anaxes-shipyard · GitHub (at github.com)
2018-10-22 17:02:16 GMT <AFaust> The only thing you can find on Docker Hub right now are those Enterprise artifacts that are used for trial installations...
2018-10-22 17:02:44 GMT <AFaust> (and those that are needed to support that use)
2018-10-22 17:02:48 GMT <yreg> Could be that I mis-interpreted comments on PRs from Alfresco staff
2018-10-22 17:04:34 GMT <AFaust> Given how little they have been communicating via blog posts or other means this year between last and next devcon, it is no surprise that there is sufficient room for mis-interpretation
2018-10-22 17:05:01 GMT <AFaust> I mean, apart from some Activiti Cloud stuff and how to get started with ACS 6, were there any other blog posts or similar publications?
2018-10-22 17:05:25 GMT <yreg> How to upgrade sdk2.x to use ACS 6.x
2018-10-22 17:05:57 GMT <yreg> Something about a 3rd party integration and why they chose something over all available possibilities
2018-10-22 17:06:04 GMT <AFaust> Right, I forgot that weird episode of using an older SDK than the one currently published to work with a new release...
2018-10-22 17:06:05 GMT <yreg> But that was it I guess
2018-10-22 17:06:47 GMT <AFaust> But can still be counted in the area of "how to get started with ACS 6" I guess..
2018-10-22 17:07:41 GMT <AFaust> I mean, regarding the Docker image question, we can do a quick comparison: What is the latest version of Enterprise release to customers / partners via Support Portal / Nexus?
2018-10-22 17:08:35 GMT <AFaust> On DockerHub I see 22.214.171.124 which looks like an anonymous update to the initial 6.0.0 release to hide some bugs they missed... (which they typically never even announce to partners / customers AFAIK)
2018-10-22 17:09:12 GMT <AFaust> Is there a 6.0.1 out already?
2018-10-22 17:09:44 GMT <AFaust> Or will they actually not do any Service Packs this time and go straight for 6.1?
2018-10-22 17:10:07 GMT <yreg> AFaust, I have seen snapshot for 6.1 some time ago
2018-10-22 17:10:11 GMT <yreg> Let me re-check
2018-10-22 17:10:35 GMT <AFaust> Sure, 6.1 EA has been out for a while, but that is also Community
2018-10-22 17:10:41 GMT <yreg> BTW heard you will be in Leuven next week, let's meet over some drinks some time
2018-10-22 17:12:36 GMT <angelborroy> This can be a sign that no one is using 6.0
2018-10-22 17:12:37 GMT <yreg> I see in nexus a 6.1-EA2
2018-10-22 17:14:32 GMT <yreg> That's annoying nexus seems to have an artefact for every branch on 6.0.0
2018-10-22 17:15:04 GMT <yreg> Or could it be hot fix tags ?
2018-10-22 17:15:10 GMT <yreg> Anyway, there is too many of them
2018-10-22 17:15:38 GMT <yreg> Same for community, so can't be a hotfix thing
2018-10-22 17:16:26 GMT <yreg> It is a bit weird to have a community version : 6.0.0-REPO-2627_Cluster-Test-1
2018-10-22 17:17:23 GMT <AFaust> Ok - coming back to my current Kubernetes state, I can see that the SOLR_CREATE_ALFRESCO_DEFAULTS is actually applied to my ASS 1.1.1 instance/pod-thingy. Will have to look for other reasons why search is not working...
2018-10-22 17:18:04 GMT <angelborroy> AFaust there were also some problems with volume permissions
2018-10-22 17:18:13 GMT <angelborroy> As Solr is lauched with user “solr”
2018-10-22 17:18:16 GMT <angelborroy> and not "root"
2018-10-22 17:18:25 GMT <yreg> Can't you simple ssh into the container and investigate further ?
2018-10-22 17:18:37 GMT <AFaust> I will look out for that... currently ssh-ing into minikube to inspect the underlying Docker containers
2018-10-22 17:18:44 GMT <yreg> S/simple/simply/
2018-10-22 17:19:01 GMT <AFaust> It is wild how many seemingly irrelevant Docker containers are up and running under the hood...
2018-10-22 17:19:45 GMT <AFaust> I have about 16 instances of k8s.gcr.io/pause-amd64:3.1 running for whatever reason...
2018-10-22 17:20:45 GMT <AFaust> Not sure when Kubernetes / minikube is supposed to reclaim these, but the oldest ones have been running for 2 hours now
2018-10-22 17:22:36 GMT <AFaust> angelborroy: The issue is even more simple than file permissions - somehow minikube / Kubernetes / Helm chart failed to set the correct Repository host name and/or provide DNS resolution
2018-10-22 17:27:08 GMT <yreg> Hate to put it all on windows always
2018-10-22 17:27:59 GMT <AFaust> Yeah, the problem is between the Content Services helm chart and the Search Services chart, which do not pass the Repository host name correctly
2018-10-22 17:28:14 GMT <yreg> But such issues are less likely to happen on other platforms <grin>
2018-10-22 17:29:06 GMT <yreg> Ah never mind, I need to call it a day now, and go back home ....
2018-10-22 17:34:31 GMT <AFaust> Hmm - strange... The solrcore.properties states alfresco.host as "localhost", but the tracking is performed against a different host name, provided via SOLR_ALFRESCO_HOST, which I cannot find used / reference anywhere except for Docker compose and Helm charts...
2018-10-22 17:46:09 GMT <AFaust> Ah... f--- it. Time to eat something...
2018-10-22 20:57:31 GMT <AFaust> Ok, so I found where the heck this SOLR_ALFRESCO_HOST is being read, and it sure is one of the hackiest / sneakiest ways I have seen that ENV variables override what has been explicitely configured in a *.properties file.
2018-10-22 20:59:11 GMT <AFaust> ConfigUtil.locateProperty() will process a dot-based property as a lookup on an underscore-based, upper-cased env variable with the SOLR_ prefix, and via its use in CoreDescriptorDecorator (https://github.com/Alfresco/SearchServices/blob/master/alfresco-search/src/main/java/org/apache/solr/core/CoreDescriptorDecorator.java#L63) a env variable can override explicit file config....
2018-10-22 20:59:12 GMT <alfbot> Title:SearchServices/CoreDescriptorDecorator.java at master · Alfresco/SearchServices · GitHub (at github.com)
2018-10-22 21:00:49 GMT <alfresco-discord> <yreg> Wow, good catch
2018-10-22 21:01:08 GMT <alfresco-discord> <yreg> how many times did you have to step into your debugger in order to find that ?
2018-10-22 21:09:18 GMT <AFaust> No debugger, because it is running in Docker inside a VM, controlled by minikube + helm. I'd have to change so many configs to get a debugger port routed through...
2018-10-22 21:09:43 GMT <AFaust> Just did a code search on every substitution / lookup pattern I could think of...
2018-10-22 21:10:16 GMT <AFaust> When looking just for "SOLR_" I finally found the ConfigUtil.locateProperty method and followed its callers back to where the alfresco.host was actually used / mentioned
2018-10-22 21:10:49 GMT <alfresco-discord> <yreg> good catch
2018-10-22 21:11:02 GMT <AFaust> The piece of code responsible for this has been in place since early 2017, but so far not much has relied on this.
2018-10-22 21:11:28 GMT <AFaust> I really don't know how to proceed with this though, since it is not a "bug". They did this on purpose...
2018-10-22 21:11:50 GMT <AFaust> But in my opinion it stinks to high heavens that an env variable can override an explicit config.
2018-10-22 21:12:20 GMT <AFaust> Essentially the same on the Repository-side though, and it has been in place there for much longer (again, not used until Docker-times)
2018-10-22 21:13:13 GMT <AFaust> With this (https://github.com/Alfresco/alfresco-repository/blob/master/src/main/resources/alfresco/core-services-context.xml#L45) even if you had bootstrapped a shared/classes/alfresco-global.properties file, you could always override everything in there via env variables
2018-10-22 21:13:14 GMT <alfbot> Title:alfresco-repository/core-services-context.xml at master · Alfresco/alfresco-repository · GitHub (at github.com)
2018-10-22 21:13:46 GMT <AFaust> In my opinion, env variables should only be allowed to override the application "defaults", i.e. anything before the shared/classes/alfresco-global.properties is loaded.
2018-10-22 21:13:55 GMT <AFaust> Similar with solrcore.properties...
2018-10-22 21:14:27 GMT <AFaust> Because at some point you have to be able to rely on explicit end-user configuration being used.
2018-10-22 21:14:57 GMT <AFaust> This whole "env vars can override everything" is just a cheap trick to have an easier time building Docker images / Helm charts...
2018-10-22 21:15:23 GMT <AFaust> But then again - this has been done deliberately, with a clear purpose, so it definitely is not a bug...
2018-10-22 21:15:52 GMT <alfresco-discord> <yreg> I had the same impression a while back
2018-10-22 21:16:18 GMT <AFaust> And I should probably focus back on my original problem of why that env variable has been given an incorrect value (different from what the Helm chart was supposed to provide)
2018-10-22 21:16:20 GMT <alfresco-discord> <yreg> but I was referring to the use of JAVA_OPTS for overriding global properties
2018-10-22 21:16:35 GMT <AFaust> That is the thing I meant with regards to Repository.
2018-10-22 21:17:14 GMT <AFaust> JAVA_OPTS -D flags - though not env vars by themselves - are essentially the equivalent on Repo-tier...
2018-10-22 21:18:50 GMT <AFaust> And in the Docker images they are so far only used to override the defaults, not the alfresco-global.properties file, because that file is extremely thin in the current images (until a customer creates a custom image on top of the default)
2018-10-22 21:19:59 GMT * AFaust remembers he has to get some clothes out of the washer and do some language exercises...
The other logs are at http://esplins.org/hash_alfresco