| *** Guest702 is now known as diablo_rojo_phone | 04:51 | |
| *** jpodivin_ is now known as jpodivin | 10:01 | |
| *** frenzy_friday is now known as frenzy_friday|doc_appt | 11:05 | |
| *** pojadhav- is now known as pojadhav | 12:38 | |
| *** frenzy_friday|doc_appt is now known as frenzy_friday | 14:33 | |
| *** dasm|off is now known as dasm | 14:46 | |
| frickler | tc-members: there has been a patch proposed https://review.opendev.org/c/openstack/project-config/+/861457 that would allow to make use of FIPS on Ubuntu by using a token somehow received from Canonical | 14:51 |
|---|---|---|
| frickler | my concern with that is that to me this does not really look like open development, so I would like to hear your opinion on this | 14:52 |
| noonedeadpunk | I guess main problem here is that we picked an Ubuntu as a main platform for PTI | 14:54 |
| noonedeadpunk | So having some way to ensure we do what we do in FIPS-compliant way is good | 14:55 |
| noonedeadpunk | But the way Cannonical does allow to check for FIPS compliance is indeed... meh | 14:55 |
| noonedeadpunk | Though we do have customers who does want to pay for ubuntu advantage just for FIPS complaince | 14:57 |
| rosmaita | well, maybe the thing to do is test FIPS on rocky linux also ... it's nice to have the ubuntu FIPS tests because it's easy to see if a problem is caused by FIPS or something else (since we have so many tests running on ubuntu) | 15:01 |
| rosmaita | frickler: would that address your concern? | 15:01 |
| fungi | the main issue raised, which i sympathize with, is that we're testing something with access to resources that people can't freely repeat on their own locally without paying for the same. though this could also be said for testing on special hardware people are unlikely to have available to them, or the sdk/cli public cloud testing plan which relies on having accounts in those clouds | 15:02 |
| fungi | frickler: do you have similar concerns over openstacksdk running zuul jobs which authenticate to a rackspace public cloud account to exercise the library's support for it? | 15:03 |
| rosmaita | yeah, my thought is that as long as there's a freely repeatable option that we're testing with, then testing with a closed one for our own convenience should be ok | 15:03 |
| frickler | fungi: my concern is tied to using non-free software mostly, the other cases you list don't involve that afaict | 15:04 |
| fungi | rackspace doesn't redistribute their changes to openstack services, nor does the apache license require them to | 15:06 |
| fungi | so there is non-free software involved in that case as well | 15:07 |
| fungi | i do wonder to what extent any of the ubuntu fips support is actually not free/libre open source. they're not required to distribute it at no cost, but that doesn't mean it isn't still f/loss | 15:09 |
| fungi | what the license gets you is access to canonical's builds, but its possible that the software you're downloading from them when you do so is still all under an osi-approved license and therefore legally redistributable through other channels. but of course we'd need to double-check that if it's a concern | 15:10 |
| frickler | rosmaita: iiuc there are currently tests set up to run on centos8/9 but they don't work well because stream is too unstable, not sure if rocky will turn out better in that regard | 15:14 |
| rosmaita | frickler: rocky is at the other end of RHEL (centos-stream is pre-RHEL, rocky is post-RHEL), so it should be pretty stable | 15:16 |
| fungi | and another option is to do it on debian, which also has fips setup tooling and would be more like ubuntu | 15:17 |
| dansmith | I have no problems with the ubuntu-based fips, and think that's by far the path of least resistance to testing what we want | 15:17 |
| fungi | i totally agree that it's a grey area though, and worth discussing | 15:18 |
| ttx | I suspect their FIPS offering is just access to a binary build that they spent $$ certifying (rather than non-free code) | 16:29 |
| fungi | that's my expectation as well, but we could get clarification on that i suppose | 16:39 |
| dansmith | yeah, because the underlying bits are all available in totally free distros like debian, AFAIK | 17:06 |
| dansmith | it's more just a particular configuration | 17:06 |
| frickler | that's an interesting thought, assuming we could solve the licensing issue, would running all our CI jobs on RHEL be still compatible with doing "Open Development"? or, more extreme, WSL2? | 17:52 |
| JayF | How are you supposed to keep CI working if developers can't reproduce a CI environment in Devstack? | 17:53 |
| fungi | frickler: the main licensing challenge with running ci jobs on rhel is that there's a carve-out in the free-to-use-for-devs rhel license that basically prohibits use in automated systems | 17:54 |
| fungi | i'd have to find the text of that again for the exact wording, but also maybe it's changed in the interim | 17:55 |
| JayF | Even using a free-to-use developer license would require an OpenStack developer to give up personal information to get it, right? | 17:55 |
| JayF | I know that's essentially the case with access to bugs/KBs that require login via RH developer accounts | 17:55 |
| fungi | yes, or to rebuild those packages | 17:55 |
| fungi | pretty sure rhel's dev licenses involve giving them personal info | 17:55 |
| frickler | my assumption is that RH or MS would give us a working license, similar to what Canonical now did. the question is would we be o.k with using it, from an open source philosophical, moral pov, not a technical one | 17:59 |
| JayF | I'm saying, who is "us"? | 18:06 |
| JayF | If "us" is infra, but an OpenStack dev still needs to pay RH with their data to be able to reproduce CI failures; that doesn't seem OK to me | 18:07 |
| JayF | sub RH with Ubuntu/MS/etc as appropriate | 18:07 |
| fungi | though as i raised earlier, it's the same if we're running a job that needs to test some specific virtual hardware support which requires licensing on the cloud side (vgpu), or sdk tests which log into a commercial public cloud provider to confirm that authenticated interactions with their api still work | 18:09 |
| fungi | if your change to openstacksdk fails the rackspace integration job, you can't personally reproduce that without paying for or convincing rax to give you a free account | 18:10 |
| JayF | I guess that's a reasonable point; or an even better example: Ironic hw drivers with only tests reproduablce in 3rd party CI or with hardware | 18:11 |
| fungi | though third-party ci jobs don't directly block merging your change (granted they may dissuade a reviewer from approving it all the same) | 18:12 |
| JayF | Still is an example of a place where a contributor needs access to non-free resources to perform development or debugging | 18:16 |
| JayF | so we've sorta already crossed that bridge then, and this seems no different in a meaningful way | 18:17 |
| frickler | having someone else run a third party CI with it is something I have suggested on the FIPS patch, that would IMO be much better acceptable than us running it ourselves. and "us" for me is the somewhat vaguely defined community assembled here, somehow representing the openstack/opendev community at large | 18:21 |
| JayF | Maybe it's just my perspective; but where it runs matters less to me than what someone would need to fix a bug in it, generally speaking | 18:22 |
| dansmith | I think we have lots of situations where fixing something in CI requires a special configuration not accessible to everyone.. FIPS is just a configuration of the underlying kernel and libraries, so this seems the least smelly | 19:00 |
| dansmith | and we've also been quick to disable the jobs we've had that failed with it, as I would expect we should/would be for any situation where replicating it is hard | 19:00 |
| gmann | I agree, and we are not testing or making our code very specific to ubuntu FIPs configuration it is just we got something (they sell free or in license ) which is very helpful for our testing. we tried centos-stream for this which did not work. | 19:13 |
| gmann | and 3rd party CI are similar example, where we are testing our code in their distro/configuration etc and fix the code during code merge or later | 19:15 |
| gmann | noonedeadpunk: this is ready to re-review, updated as per the review comments https://review.opendev.org/c/openstack/governance/+/860599 | 20:12 |
| gmann | tc-members: need one more vote in this https://review.opendev.org/c/openstack/governance/+/863161 | 20:15 |
| JayF | RC+1 from me gmann | 20:15 |
| gmann | thanks | 20:16 |
| opendevreview | Merged openstack/governance master: Add zookeeper role under OpenStack-Ansible governance https://review.opendev.org/c/openstack/governance/+/863161 | 20:24 |
| *** dasm is now known as dasm|off | 22:44 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!