18:00:13 #startmeeting Fedora Infrastructure Ops Daily Standup Meeting 18:00:13 Meeting started Tue Jun 13 18:00:13 2023 UTC. 18:00:13 This meeting is logged and archived in a public location. 18:00:13 The chair is phsmoura. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:00:13 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:13 The meeting name has been set to 'fedora_infrastructure_ops_daily_standup_meeting' 18:00:13 #chair nirik smooge phsmoura 18:00:13 #meetingname fedora_infrastructure_ops_daily_standup_meeting 18:00:13 #info meeting is 30 minutes MAX. At the end of 30, its stops 18:00:13 #info agenda is at https://board.net/p/fedora-infra-daily 18:00:13 Current chairs: nirik phsmoura smooge 18:00:13 The meeting name has been set to 'fedora_infrastructure_ops_daily_standup_meeting' 18:00:23 hello 18:00:31 morning. 18:00:40 * nirik hopes this is quick... I'm out of coffee. ;) 18:01:23 yep we dont have much new issues today 18:01:26 #info reminder: speak up if you want to work on a ticket! 18:01:26 #topic Tickets needing review 18:01:34 #info https://pagure.io/fedora-infrastructure/issues?status=Open&priority=1 18:01:38 thats always good. 18:01:48 .ticket 11371 18:01:49 phsmoura: Issue #11371: Decommission of Nuancier - fedora-infrastructure - Pagure.io - https://pagure.io/fedora-infrastructure/issue/11371 18:02:29 med med ops I guess? 18:02:45 One thing to note: this is not a openshift app. Its got real vm's. 18:02:54 this is tagged, anything to add on this. Ill just change its priority to not appear in this filter 18:03:05 ok. 18:03:13 its has low gain med trouble 18:03:16 I'll add my note about openshift after you adjust it. 18:03:30 should be changed? 18:03:43 naw, thats ok too I guess. 18:03:51 ok, done 18:04:37 we dont have new issues in releng 18:05:18 \o/ 18:05:37 #topic Planning, Upcoming work and Open floor 18:05:59 #info next monday is a holiday for US Red Hat employees 18:06:26 I've been catching up on things, hopefully today I will get back to rhel9 stuff and possibly some documentation. 18:07:29 hey o/ I've been looking into awx a bit more lately 18:07:37 I started working on tests in dnf countme 18:07:51 cool on both. ;) 18:08:09 darknao: let me know if I can help/answer any questions on it... 18:08:19 and not sure how to proceed now: most playbooks/roles use hardcoded paths like /srv/web/infra or /srv/private that are only available on batcave01 18:08:47 and that will not work with awx as everything runs inside containers, unless we use hostpath for everything 18:09:12 yeah, we hit that in the past with trying to use stuff for a test env or the like. 18:09:29 but that means awx need to runs playbooks on batcave01, as I don't think we can access those path from somewhere else like a dedicated batcomputer01 18:09:29 perhaps we could now abstract away that path to a variable(s)? 18:09:52 oh I see. yeah... 18:10:12 unless the /srv/private thing is a git repository or something that we can share between the two hosts? 18:10:27 for the main ansible repo, we could do what we do for batcave (have a fedora-messaging listener that syncs it), but that wouldn't work for private. 18:10:31 it is a git repo yes. 18:11:49 the alternative would be to just start with awx for some dedicated playbooks that doesn't requires those private files, like proxy syncs or something like that 18:11:50 I suppose I could move those both out to a nfs volume? then we could use that multiple places... but would have to be careful not to expose anything 18:12:08 then try to adapt our other playbooks to work on both awx/ansible-core 18:12:33 yeah, that would also have the advantage of letting us fix/drop a bunch of cruft. 18:12:49 I assume awx has vault integration for secrets? 18:13:27 yes, but that's mainly for variables like password or certificates/key files 18:13:53 you can't store files in it, unless if you base64 encode everything 18:13:54 I suppose we could consider also setting up a gitlab subproject for the backing... 18:14:14 ok 18:15:17 yeah I was wondering about gitlab project too, we'll need to build our own Execution Environment with our dependencies in it, and we could use gitlab-ci to build it automatically 18:15:20 At least for now, I'm good with the idea of just setting it up the way it expects and see if we can migrate or adapt to it or adapt it as needed after the POC is there to play with? 18:15:49 yeah, that might be useful then. 18:15:55 I also tried to set it up with ipa/ipsilon using saml2, and that work just fine 18:16:14 it expects all roles to be seperate git repos? or how is the repo organized? 18:16:26 monorepo is ok 18:16:38 the downside of gitlab is it makes us dependent on it... 18:16:43 I don't think we need to restructure everything just yet 18:17:33 can it just use it's own repo locally? or does it expect to pull from somewhere externally? 18:18:15 (and I assume it has it's own database, etc) 18:18:20 yeah remote repository is mandatory 18:19:19 anything else? 18:19:27 this is sounding familiar with the last time we looked at AWX 18:19:47 nothing from me 18:19:48 I mean, you can use a local repository, but that's not recommended, and I'm not sure how it'll behave with execution nodes 18:20:01 the problem the last time was it was like a month after it was opensourced and nothing worked. ;) 18:20:35 ok. Perhaps we should just make a pagure.io/fedora-infra/ one for the poc? 18:21:08 does the saml2 integration get groups? or can it do oidc? 18:21:12 that would be a good start 18:21:31 the latest version of awx can do oidc 18:21:57 and yes, you can get groups and everythings 18:22:01 cool! It's deployed as a operator? or ? 18:22:27 anyhow, I'm excited. ;) We should stand up the POC in our clusters and poke at it. 18:22:29 yes, it's the preferred way to deploy 18:22:54 the deployment is very straightforward 18:22:59 many thanks for looking into it! 18:23:36 nice. 18:23:53 we can continue in noc. ;) I didn't have anything else for this today off hand... 18:24:09 ok, thanks you all for joining :) 18:24:14 #endmeeting