hi @jscotka ,

We can clearly create dedicated openidc key/secret and application id on https://id.centos.org but we'd just like to verify from where you'd be using that .
Have you already deployed a public openqa instance for this that people will be able to interact with ?
You don't seem to have listed your gpg pub key on your FAS account but eventually I can just sent these to @bookwar once we'll have the needed info :)

Hi Fabian,
No, I have not public instance of openqa now, as I have to verify it locally first how it works with Oauth2, then I plan to use duffy client and ask for resources for openQA server, to avoid security hazards with default fake authentication within public instance.
Yep, I do not have GPG key there. I've never needed this.

Is it viable for you to encrypt it with my ssh RSA public key what is published inside my FAS account? or theoretically you can also sent it to @bookwar, but still there will be the issue how to transfer the key to me then :-) as I'll do these configurations
Thanks&Regards
Honza

@jscotka : I think we have a kind of "chicken and egg" issue here as for openidc I need to already know the callback url at your side, so that identified clients through openidc would get back to your public instance ..
I'd be all against running something like your main openqa server on an ephemeral (6h) infra, so I was suggesting where to run the tests, and not openqa main server on same infra :)
@bookwar : is there a way to discus that in a mail on centos-devel list or irc instead of async discussion in a ticket tracker ? having a kind of overview would help to understand :)

@arrfab as we've tried to solve the problem inside https://pagure.io/centos-infra/issue/1631 with nested virt. I plan to run main OpenQA server just as web fronted and database, and test (workers) will run on temporary resources, so that from that perspective I do not need to have nested or full virt support there. SO situation will be then simplier.
But still I need permanent resources for this frontend. I expect that via this duffy client I can ask for permanent resources, or it is intended just for temporary ones?

@jscotka see where the communication problem is ? :-) in the other ticket it was about machine where to test things but not about your permanent machine (which I wasn't even aware of, as never discussed with infra team at all, reason why I asked for a public thread on centos-devel list or irc)

Duffy is all about ephemeral machines (6h max) : https://docs.centos.org/centos-sig-guide/ci/#duffy-ephemeral-bare-metalvirtual-machines-provider : ephemeral bare-metal/Virtual Machines provider

Can you come with a full description of what you want to achieve and why and only then come with a request that we can then understand and help you with please ? :)

From what I understand now (but correct me if I'm wrong) , you'd need :

• permanent EC2 instance to run openqa instance (frontend and DB)
• duffy api key to then provision on demand ec2 instance[s] for the test.

Does that sound right ?

@arrfab yes you are right.
The first idea were to have everything on one machine with some virt support, to finalize the solution before final production deployment, as described in https://pagure.io/centos-infra/issue/1631 , but after discussion because of temporal resources with virt support we've decided to split it into several steps:

• permanent machine for frontent and DB internally splitted into podman containers
  • where I need to use Oauth2 to have stronger authentication for openQA instance.
• on demand workers to run tests with virt support, (this is for now optional, as I expected for testing purposes to requrest them manually)
  • but yes, you solution with duffy api key for dynamic resource allocation is the ideal solution.
  • Theoretically we can use there also resources of testing farm, but this will be more complicated. Will be implemented in future.

And I've expected to be able to use duffy also for permanent resources in case it will be EC2 instance, I've probably misunderstood this part, not shared bare metal resources.

But yes, the communication problem is there, because I've described the https://gitlab.com/CentOS/Integration/general/-/issues/8 , but It was without implementation details. And I've expected to be able to split my issues to be able to solve each one separately, to be as simple as possible for requests, without connections, but I've met these chicken/egg problems with Oauth2, and misunderstanding my solution why I need virt support, and why I wanted to implement it on one machine as first working solution to avoid complication with dynamic resource handling for workers :-)

Thanks
Honza

Let us know when you'll have the callback url ready and I'll be able to proceed with the counterpart on id.centos.org setup (and then securely transmit you the id/secret)

addind fedora Oauth ticket to the conversation: https://pagure.io/fedora-infrastructure/issue/12459 as there will be similar patter for endpoint. I'll discuss it with Adam later.

@jscotka : let me know when you have all info that you need and then we can proceed

@jscotka : still waiting so if you don't know the details, we can probably close this ticket and you'll reopen it when you'll have the callback url for your app ?

no feedback for long time so closing and feel free to reopen if you still need this