Mordred should be able to read a remote projects.json file from Gitlab about grimoirelab-sirmordred

[valeriocos]

Reading a projects json from a URL is supported: https://github.com/chaoss/grimoirelab-sirmordred#projects. Can we close this issue @sanacl @jgbarah @jgbarah ?

[jgbarah]

I'm not opposing this functionality, but I just wonder if it wouldn't be better to keep SirMordred as it is, and do that kind of stuff with ansible, or whatever the deployment tooling that people are using. (Just a comment, please ignore if you think I don't have enough context)

[canasdiaz]

@jgbarah the thing is in production we don't have a way to allow our users to modify the projects.json in real time. They have to wait for us until we apply the changes. This is why I see this needed.

If you think it creates a conflict with the community requirements let's discuss it :)

[jgbarah]

No, no conflict that I can see. Just some extra complexity in SirMordred, which maybe could be dealt with the deployment tooling. In the case of ansible, I just wondered if anyone managing files in GitLab could update the projects.json file, and ansible will just check the repo whenever convenient, updating the local copy of the file if needed, and re-launching SirMordred afterwards.

Some basic approach to something akin to this is available at https://codereview.stackexchange.com/questions/175616/clone-a-gitlab-private-repo-with-ansible

But again, if you have this as a clear requirement, please just ignore the noise.

[canasdiaz]

@jgbarah the thing here is we should be coherent with the solution provided to read projects and identities files. If a solution with a bot like the one you propose is simpler I would buy it. In any case I don't know such cheaper solution based on a bot. On the other hand, if we set as a requirement that the tool should be easily dockerized, it is better to allow to read remote configuration files to avoid dealing with volumes and so on.

[jgbarah]

OK, I see. No problem on my side.

[jsmanrique]

Perhaps it's the same requirement, but reading a .json file looks quite similar to reading from an API. And AFAIK, ES stores things in json format, so it looks even more similar to reading from a query to ES.

Having said that, it would be easier to read and write from and in ES with a web UI, than modifying a .json file.

This way, the solution is more agnostic (not tied to @sanacl deployment needs).

Just my 2 cents

[jgbarah]

I think that would amount (with respect to download) too specifying an url... Which could be pretty much the same as if we do that from GitLab, I think.