My comment on this: I've been approached with releng (Mohan and Tomas Hrcka) with a question whether they could use ODCS for Fedora Minimal Compose. Based on this test, they would eventually build more composes using ODCS. The El Nino project has very similar needs. I suggested that we could share this particular VM in the early stages to debug this new ODCS use-case and compose process instead of doing that twice on two VMs - one for Fedora Minimal Compose and one for El Nino project.

We are going to have to close this can't fix until August. We are going to be at bare minimal systems from May to July and services which were not outlined earlier this year will not be available during that time.

So, I agree with smooge 100% here that we can't run such an instance during the datacenter move... we simply didn't plan for it.

That said, if you want an instance now (that will likely be turned off when we start the datacenter move... ie, may) we can do that for short term testing.

So, you would want for that a new vm that would run another odcs instance? Or another odcs backend? can you explain how it would be setup?

@kevin, I will answer that because I would be setting up the backend. It would be new backend for current ODCS prod instance. It would be configured to handle only releng composes needed for their ODCS tests. The odcs/backend role would be deployed there configured to handle compose tasks in new ODCS Celery queue for the composes initiated by the releng team members.

I cannot say how urgent these tests are for relengs, but I'm pretty sure the current ODCS prod backend is just too small for these composes without blocking some real composes running there from time to time. Therefore if relengs have a need to start working on this, it makes sense to setup even temporary backend now. I'm OK deploying such backend for relengs and then doing it again in new datacenter.

The backend can easily be removed at any time if relengs agree with that. From ODCS point of view, the machine can just disappear at any time and everything will work as expected, because it would be the only machine connected to that new Celery queue and the queue will be used only by relengs.

Thanks @jkaluza for the explanation, I didn't see this message yet, but I already talked to @kevin in the morning asking for a new temporary machine, provided if they have any spare resources.

ok, odcs-backend-releng01 has been created. It's in the prod odcs_backend group so it was installed and configured just like the odcs_backend01 machine.
(with the exception that I disable fedmsg on it... has odcs moved to fedora-messaging yet? If it hasn't I can make a cert, but if it has we should remove the fedmsg role calls in the playbook).

Feel free to adjust it from there via the playbook, or let me know if you need anything else.

Note again that this machine will go away when we are migrating datacenters. We can bring it back up after the migration is all done.

Hm, fedmsg should be disabled on ODCS backends already. In case you wanted to disable the backend, you were supposed to "systemctl stop odcs-celery-backend". But it does not break anything to keep it running there even now. I will take it from here and do the configuration as part of ODCS upgrade I will be doing tomorrow.

Thanks @kevin.

Thanks. Yes, please do remove the fedmsg stuff from the playbooks if it's no longer using it. Helps us avoid confusion. :)