logan- | i'm trying to find a way to modify the config repo gerrit acl in a way that does not get overwritten by sfconfig on the next run, is that possible? | 00:51 |
---|---|---|
logan- | ah I see that it is not possible | 01:13 |
*** sbadia has quit IRC | 01:45 | |
*** sbadia has joined #softwarefactory | 01:46 | |
*** ChanServ sets mode: +o sbadia | 01:46 | |
*** bhavikdbavishi has joined #softwarefactory | 02:45 | |
sfbender | Logan V created software-factory/sf-config master: Allow customization of config gerrit ACL https://softwarefactory-project.io/r/15160 | 04:03 |
logan- | greenfield letsencrypt deployment is broken currently. sf-gateway runs an apache2 reload, which fails because the lecm role has not run yet so the cert file does not exist yet. | 04:21 |
logan- | in other projects I work around this by generating a self signed cert to bootstrap with, then replace it with a letsencrypt cert later on. | 04:21 |
logan- | just an idea but that might work here | 04:22 |
*** nijaba has quit IRC | 04:26 | |
tristanC | logan-: indeed that's an issue, perhaps we could copy the default cert in /etc/letsencrypt for the first reload | 04:43 |
tristanC | logan-: though, sf-lecm should be running before sf-gateway... | 04:44 |
logan- | hmm | 04:45 |
logan- | correction, the failure is in sf-cauth | 04:45 |
logan- | although that's on a sfconfig run where sf is already deployed and I tried to flip the letsencrypt switch | 04:47 |
logan- | I can't remember where it failed on greenfield | 04:47 |
tristanC | logan-: 15160 looks correct | 04:47 |
tristanC | logan-: iirc we used to have a test that setup letsencrypt on greenfield and it worked | 04:47 |
tristanC | logan-: and switching it on later should also work. if you have some logs to share, we can have a look | 04:48 |
tristanC | logan-: also, note that cauth mush be running on the gateway host too, this is now enforced by https://softwarefactory-project.io/r/#/c/15124/ | 04:49 |
*** nijaba has joined #softwarefactory | 04:53 | |
logan- | gotcha - I will get some logs gathered up tomorrow for the letsencrypt issue. I fixed up and tested 15160 for idempotency with the old config, and its identical now. | 05:04 |
logan- | thanks! | 05:04 |
sfbender | Tristan de Cacqueray created DLRN master: logging: refactor basicLogging configuration https://softwarefactory-project.io/r/15164 | 05:48 |
tristanC | jpena|off: jruzicka: we are struggling to figureout how to let the user configure distroinfo and the dlrn.cfg file... | 07:22 |
tristanC | jpena|off: jruzicka: why isn't the dlrn.cfg part of the distroinfo? and or, should dlrn be able to generate the dlrn.cfg based on the existing distro-info? | 07:22 |
fbo | the mock config | 07:28 |
*** jpena|off is now known as jpena | 08:14 | |
jpena | tristanC, fbo: well, we never thought about the possibility of generating the mock config, since it's always been quite specific to the environment (base repos, chroot-installed packages and such). Looking at rdoinfo, it might be possible to generate the repos part based on https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml#L34-L42, but I see it as a quite specific use case. I mean, having an external tool generate the | 08:20 |
jpena | configuration based on that looks fine to me, but I wouldn't make it part of DLRN (too tight coupling) | 08:20 |
tristanC | jpena: external repos would make sense, it's a duplicated conf, and dlrn already inject its own repository | 08:22 |
tristanC | jpena: and for the rest of the mock config, would you use different one for the same distroinfo ? | 08:23 |
jpena | tristanC: yes, we use different ones when building for rhel 7 or 8, for example | 08:24 |
jpena | also, not every driver depends on distroinfo | 08:24 |
tristanC | jpena: but rdoinfo only has el7 information... | 08:25 |
jpena | tristanC: right, so that's why I don't want to couple it too tightly | 08:25 |
jpena | with the same distroinfo information, we're currently building for el7, fedora and el8 | 08:26 |
tristanC | jpena: ok, make sense, but then , shouldn't we remove the distrepos from distroinfo ? | 08:27 |
jpena | tristanC: from the DLRN point of view we could, I don't know if it is used for any other purpose | 08:27 |
tristanC | jpena: oh ok, i think it would be clearer. it's confusing to set distrepo both in distroinfo and in dlrn mock.cfg | 08:28 |
tristanC | e.g., from a new user perspective, it is confusing to set build target and distrepo in both places | 08:31 |
*** sshnaidm has quit IRC | 08:51 | |
tristanC | hmm, grafiti probably needs distrepo information | 08:51 |
*** sshnaidm has joined #softwarefactory | 08:52 | |
*** bhavikdbavishi has quit IRC | 10:30 | |
sfbender | Tristan de Cacqueray created software-factory/sfinfo master: format-patch: remove git global https://softwarefactory-project.io/r/15167 | 10:48 |
sfbender | Merged software-factory/sfinfo master: Add path exclusion and rename 'cat' by 'note' https://softwarefactory-project.io/r/15063 | 10:51 |
*** bhavikdbavishi has joined #softwarefactory | 11:16 | |
*** rfolco is now known as rfolco|rucker | 12:08 | |
jruzicka | tristanC, so you don't like duplication of information in rdoinfo and dlrn mock.cfg, correct? | 12:11 |
jruzicka | distroinfo is just a simple parser/templater/fetcher, it knows nothing like certain John ;) | 12:12 |
jruzicka | jpena, hey! so let's assume I have all the pieces after patch_rebaser in place (which I don't :D), where should I put them? will there be a script calling individual preprocessing steps or...? | 12:20 |
jpena | jruzicka: we have a script that calls patch_rebaser, so it could call the extra preprocessing step | 12:20 |
jpena | alternatively, we can configure DLRN to run several preprocessing scripts in order | 12:20 |
jruzicka | jpena, where does it live? | 12:20 |
jpena | jruzicka: right now, it's in the osp trunk VM | 12:21 |
jpena | #!/bin/bash | 12:21 |
jpena | source ~/patch_rebaser/.venv/bin/activate | 12:21 |
jpena | python ~/patch_rebaser/patch_rebaser/patch_rebaser.py | 12:21 |
jpena | ^^ pretty simple ATM | 12:21 |
jruzicka | jpena, and expected result is the updated distgit, right? does it matter at which branch does the script end? | 12:22 |
jpena | jruzicka: no, doesn't matter | 12:22 |
jruzicka | jpena, so I say just add `git co $DISTGIT` and `rdopkg patch -l` to that script and we only have the proper changelog left and I'm reading them cards about that right now. | 12:25 |
jpena | jruzicka: I guess that would work | 12:28 |
jruzicka | why shouldn't it? :) | 12:28 |
jruzicka | if it won't work I'll make it work :D | 12:29 |
jruzicka | worked for me, though | 12:29 |
*** jpena is now known as jpena|lunch | 12:46 | |
*** rfolco|rucker is now known as rfolco|ruck | 12:57 | |
*** jpena|lunch is now known as jpena | 13:50 | |
sfbender | Javier Peña created DLRN master: Refactor downstream driver filtering https://softwarefactory-project.io/r/15170 | 14:10 |
sfbender | Matthieu Huin created software-factory/sfinfo master: Add python-jsonpath-rw https://softwarefactory-project.io/r/15172 | 17:19 |
*** jpena is now known as jpena|away | 17:30 | |
*** sshnaidm is now known as sshnaidm|off | 17:47 | |
*** irclogbot_3 has joined #softwarefactory | 18:03 | |
sfbender | Jon Schlueter created rdopkg master: WIP: expand test_guess unit test coverage for patches branch https://softwarefactory-project.io/r/15173 | 18:29 |
*** bhavikdbavishi has quit IRC | 19:21 | |
*** jpena|away is now known as jpena|off | 19:32 | |
logan- | tristanC: following up on that letsencrypt stuff from yesterday. here are 2 logs, the first is a greenfield deploy w/ letsencrypt enabled. the second is a deploy without letsencrypt, then attempting to flip the letsencrypt flag on and sfconfig. both fail the same way it seems like. | 20:04 |
logan- | tristanC: greenfield letsencrypt https://pasted.tech/pastes/68219754a5624efc62b16d58854965e2a57cc859.raw | 20:04 |
logan- | and a separate deploy without letsencrypt, attempting to flip it on afterward and re-sfconfig: https://pasted.tech/pastes/080cc900dda228c2a844082f9af029b6cdf17ee8.raw | 20:04 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!