#8035 A few final ansible secrets for kerneltest
Closed: Fixed 2 months ago by kevin. Opened a year ago by jcline.

There's a "kerneltest_secretkey" for the kerneltest web application to use, but no corresponding "stg_kerneltest_secretkey" variable, so I need someone to collect some small batch, home grown, organic entropy and place it in an ansible variable with that name.

kerneltest is also moving to openid connect so it's going to need the OIDC variables and secrets. It looks like other apps have "<app>_oidc_client_id", and then "<app>_oidc_client_secret" and "<app>_oidc_client_secret_stg".

Thanks!


I actually already made that, but it's called: 'kerneltest_stg_secret_key'

Do you need prod and staging OIDC? Do you need any scopes? (see: https://fedoraproject.org/wiki/Infrastructure/Authentication )

Metadata Update from @kevin:
- Issue priority set to: Waiting on Assignee (was: Needs Review)

a year ago

Ah, cool.

For OIDC yeah, staging and prod would be good. Patrick set up some scopes for me I think when I was doing the development, https://fedoraproject.org/wiki/Infrastructure/Authentication#github.com.2Fjmflinuxtx.2Fkerneltest-harness should be what's there.

Metadata Update from @cverna:
- Issue tagged with: backlog

a year ago

Hey @jcline do you still need that ?

If so there is a template with a few questions :S

To help us register your application in our OIDC service, we need a few information
from you:

Note: all the default values provided here are based on the default choice/implementation
of flask-oidc. If you do not use this library you may have to refer to the documentation
of your library.

Some generic information first:
- What is the application main URL?
- Who will be the main contact for the application, or will this be core infrastructure?
- What privacy policy will be applicable to the application, or will this be the standard Fedora privacy policy?

Some more OIDC specific information then:
- Which redirect URI(s) will the application use?
- flask-oidc defaults to : <application_url>/oidc_callback but it's configurable (so double-check)
- Does the application need the user names, or will an application-specific pseudonym suffice?
- ie: using flask-oidc, do you ever rely on OIDC.user_getfield('sub') to get the user's username?
If not, this question likely does not matter for your application
- Which authorization flow does the application use?
- flask-oidc: authorization_code (
- Which token authentication method does the application use?
- flask-oidc: client_secret_post
- Which response type does the application rely on?
- flask-oidc: Code

Confirmed with @jcline that he not interested into pushing that ticket anymore.

Closing

Metadata Update from @cverna:
- Issue close_status updated to: Will Not/Can Not fix
- Issue status updated to: Closed (was: Open)

6 months ago

The fedora kernel maintainers are very interested in keeping this app going.

Could someone from our team finish moving it into openshift? Then @jcline and/or @jforbes could maintain it and we just run it?

Metadata Update from @kevin:
- Issue status updated to: Open (was: Closed)

5 months ago

ok. I think the OIDC setup is already done.

The staging app needs to be added to proxy01.stg so it can be reached.

Once we have that we can see how the stg one looks and then roll it into prod after that...

I added the app to stg proxy01, fixed a few things in openshift, but now it won't deploy right. It says:

ERROR: don't know how to run your application.
Please set either APP_MODULE, APP_FILE or APP_SCRIPT environment variables, or create a file 'app.py' to launch your application.

but APP_MODULE is indeed set and it seems right. If anyone has ideas, feel free to fix it, and it should come up on https://app.stg.fedoraproject.org/kerneltest

ok, got past those things... I fixed the image and now it crashloops. ;)

FileNotFoundError: [Errno 2] No such file or directory: '/etc/kerneltest/client_secrets.json'

Can't seem to find it's secrets. They look ok to me, so I am likely just missing something... if anyone has ideas, feel free to fix.

I have two remaining issue:

  • The route to apps.stg.fp.o doesn't work in openshift, I'm getting:
 "stderr": "The Route \"kerneltest\" is invalid: spec.host: Invalid value: \"apps.stg.fedoraproject.org/kerneltest\": host must conform to DNS 952 subdomain conventions"

when running the playbook.

Should we switch to kerneltest.stg.fedoraproject.org ?

The logs are saying:

Loading configuration from /etc/kerneltest/config.toml
API_KEY is not configured, falling back to the default. This is NOT safe for production deployments!

so I guess something is missing in the configuration file.

I've switched the domain to https://kerneltest.stg.fedoraproject.org/ and as you can see it almost works :)

Locally, in the pod, a curl http://localhost:8080 works and returns html, somehow something is still not right though :/

And we are live: https://kerneltest.stg.fedoraproject.org/ \รณ/

Anything we need to do on this?

@jcline @jforbes do you want this to be deployed in production ? or should we close that ticket ?

On Fri, Apr 17, 2020 at 2:22 AM Clement Verna pagure@pagure.io wrote:

cverna added a new comment to an issue you are following:
@jcline @jforbes do you want this to be deployed in production ? or shoul= d we close that ticket ?

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-infrastructure/issue/8035

Not for at least a week. It is kernel test week this week, and I need to
gather the data from it early next week.

Justin

Still waiting on @jforbes green light to deploy in prod.

Unfortunately, it is going to be a while. Upon review, there was a decent amount of work not done yet, and with @jcline no longer on the kernel team, and ARK being in full swing, I just don't know when I will get to it. The good news is, what we have been using works fine, and will do so for a while.

So, thats unfortunate. We were hoping to move this into openshift so we could more easily move it with the datacenter move.

Can kerneltest just be down for a while during the move? ie, jun 8th to later in june when we get hardware that was shipped setup and are readding things? Do you only use it for test days/weeks? or more often?

If it can't be down, we will have to try and see if we have room for it somewhere, as we were hoping it would be in openshift. ;(

So, I am going to just close this as we have the new app all ready to deploy, but from talking with @jforbes it needs some more work before it will be ready to take over for the vm one.

As soon as thats ready we can deploy the openshift one.

@jforbes please let us know if we can assist any further here.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 months ago

Login to comment on this ticket.

Metadata