Wednesday, 2023-11-15

opendevreviewGregory Thiemonge proposed openstack/octavia stable/wallaby: Fix incorrect removal of IP rules in the amphora  https://review.opendev.org/c/openstack/octavia/+/90098308:13
skraynevgthiemon1e: hello. I am wondering, why it's not possible to use SSL cert with empty CN (common name) for HTTPs Terminated listener? 10:02
skraynevlooks like ha-proxy allows it, but octavia parse CN and fails if it's empty10:02
skraynevI talk about this part of code: https://github.com/openstack/octavia/blob/7310986de9bf68ed86de90de0501a1bc46945526/octavia/common/tls_utils/cert_parser.py#L262-L26510:03
gthiemon1eskraynev: hmmm no idea10:25
gthiemon1eskraynev: what's the issue? an exception when getting the attributes?10:25
skraynevyeap. I try to use SSL certificate with empty CN field on creation listener and it fails with error: Unreadable Certificate.  it happens exactly in the place which I mentioned above, because: `cert.subject.get_attributes_for_oid(x509.OID_COMMON_NAME)` returns empty list10:31
skraynevso I try to figure out the reason, why does code expect cn will be not empty10:32
gthiemon1ethe CN is set in the TLSContainer object: https://github.com/openstack/octavia/blob/7310986de9bf68ed86de90de0501a1bc46945526/octavia/common/tls_utils/cert_parser.py#L40710:35
gthiemon1ebut the primary_cn attribute is never used10:35
skraynevyes. I understand, that this case is should be defined, but it also looks like it could be None. for example in old code it had soft validation: https://review.opendev.org/c/openstack/octavia/+/184868/4/octavia/common/tls_utils/cert_parser.py#b10610:42
skraynevmaybe someone from authors of this review could shed a light on the using CN attribute? however I don't see them online (or don't know right nickname :) )10:44
gthiemon1ewow that's old10:58
opendevreviewTom Weininger proposed openstack/octavia master: Clarify the client_ca and agent_server_ca options  https://review.opendev.org/c/openstack/octavia/+/90101711:25
opendevreviewMerged openstack/octavia stable/zed: Fix incorrect removal of IP rules in the amphora  https://review.opendev.org/c/openstack/octavia/+/89394111:35
opendevreviewMerged openstack/octavia stable/yoga: Fix incorrect removal of IP rules in the amphora  https://review.opendev.org/c/openstack/octavia/+/89394211:39
opendevreviewMerged openstack/octavia stable/xena: Fix incorrect removal of IP rules in the amphora  https://review.opendev.org/c/openstack/octavia/+/89394311:39
opendevreviewTom Weininger proposed openstack/octavia master: Clarify certificate related config options  https://review.opendev.org/c/openstack/octavia/+/90101711:39
skraynev@gthiemon1e indeed :) 11:50
skraynevgthiemon1e: I put all information to the bug description: https://bugs.launchpad.net/octavia/+bug/2043582. it will be great if someone else take a look on it.12:06
gthiemon1eskraynev: ack, we have our weekly meeting today, we can discuss it12:12
skraynevgthiemon1e: sounds great. thank you.12:15
gthiemon1eskraynev: "that certificate without SSL is not allowed" you mean without CN, right?12:20
skraynevyes12:20
skraynevthank you for catching this misspell12:21
opendevreviewTom Weininger proposed openstack/octavia master: Clarify certificate related config options  https://review.opendev.org/c/openstack/octavia/+/90101713:13
opendevreviewTom Weininger proposed openstack/octavia master: Clarify certificate related config options  https://review.opendev.org/c/openstack/octavia/+/90101713:51
opendevreviewTom Weininger proposed openstack/octavia master: Clarify certificate related config options  https://review.opendev.org/c/openstack/octavia/+/90101713:52
opendevreviewMerged openstack/octavia stable/2023.1: Fix incorrect removal of IP rules in the amphora  https://review.opendev.org/c/openstack/octavia/+/89378014:56
*** gthiemon1e is now known as gthiemonge15:55
gthiemonge#startmeeting Octavia16:00
opendevmeetMeeting started Wed Nov 15 16:00:21 2023 UTC and is due to finish in 60 minutes.  The chair is gthiemonge. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
opendevmeetThe meeting name has been set to 'octavia'16:00
gthiemongeo/16:00
oschwarto/16:01
tweiningo/16:03
gthiemonge#topic Announcements16:04
gthiemonge* 2024.1 Caracal Release Schedule: Caracal-116:04
gthiemongethis week is Caracal-116:04
gthiemongepatches for new releases of octavia-lib and python-octaviaclient have been proposed16:04
gthiemongehttps://review.opendev.org/c/openstack/releases/+/90076016:04
gthiemonge#startmeeting Octaviahttps://review.opendev.org/c/openstack/releases/+/90077716:04
opendevmeetgthiemonge: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.16:04
gthiemongeoops16:04
gthiemongehttps://review.opendev.org/c/openstack/releases/+/90077716:04
gthiemongenote: the fix in python-octaviaclient was already included in a bugfix release16:05
tweiningyou mean the hsts "fix"16:06
gthiemongeyep16:06
gthiemonge#topic CI Status16:08
gthiemongeFYI we are facing 2 recurring errors in the CI16:08
gthiemongea DB deadlock (due to the rework for sqlalchemy 2)16:08
gthiemonge"Potential deadlock in check_quota_met during the first call of a tenant"16:08
gthiemongehttps://bugs.launchpad.net/octavia/+bug/203879816:09
johnsomo/16:09
gthiemongethere are 2 patches that should fix it16:09
gthiemongehttps://review.opendev.org/c/openstack/octavia/+/89966316:09
gthiemongejohnsom: \o16:09
gthiemongethe 2nd error is: "greenlet.error: cannot switch to a different thread"16:09
gthiemongehttps://bugs.launchpad.net/octavia/+bug/203934616:09
gthiemongethere's a thread on the ML about eventlet16:10
gthiemonge[all][tc][ptls] Eventlet: Python 3.12, and other concerning discoveries16:10
gthiemongeif we drop eventlet, it will fix our issue :D16:10
johnsomBut that will be probably D or E release I would expect.16:11
johnsomThat is a hard turn for a big ship....16:11
gthiemongejohnsom: so maybe we need to report this issue to oslo.messaging16:12
johnsomYeah, I think we might want to pursue fixing oslo messaging16:12
gthiemongejohnsom: based on some queries I did in opensearch, it also impacts other projects16:13
johnsomYeah, there are definitely reports from other projects16:13
gthiemongerecent reports?16:13
johnsomI sent you some links, they start in 2021 and are still open on the eventlet side, but a recent change in oslo messaging seems to have increased it16:15
johnsom#link https://github.com/eventlet/eventlet/issues/66216:15
johnsomfor example16:15
gthiemongeoh yeah I saw some old reports but that specific issue was addressed16:15
johnsom#link https://github.com/eventlet/eventlet/issues/43216:15
johnsomLet me find the oslo messaging patch, give me a minute or two on that16:16
gthiemongebecasue that issue reappeared in october 202316:16
johnsomThere is this one too: 16:17
johnsom#link https://github.com/ChameleonCloud/zun/issues/1516:17
gthiemongeack16:19
johnsomThere is some chatter that this change make the occurrence more often: 16:19
johnsom#link https://github.com/openstack/oslo.messaging/commit/fd2381c723fe805b17aca1f80bfff4738fbe962816:19
johnsomI think the heartbeat_in_pthread setting should block all import and reference to eventlet in oslo messaging, which is not the case today.16:20
johnsom#link https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_utils.py#L2516:20
gthiemongehmm ok16:22
gthiemongeunfortunately I don't reproduce it in my env, I ran the tests during 12h, not a single occurrence of the bug16:22
johnsomI think it triggers when rabbit has an issue, like a network interruption, but I don't have a reproducer either16:23
gthiemongeok, I will report it to the oslo.messaging launchpad, I'll share the link here16:24
gthiemongemaybe my env is not really up-to-date16:25
johnsomI saw it in the check gates16:26
gthiemongeyeah many times16:26
gthiemonge#topic Brief progress reports / bugs needing review16:29
gthiemongethere's a new bug reported by skraynev:16:29
opendevreviewTom Weininger proposed openstack/octavia master: Clarify certificate related config options  https://review.opendev.org/c/openstack/octavia/+/90101716:29
gthiemongehttps://bugs.launchpad.net/octavia/+bug/204358216:29
gthiemongebasically Octavia rejects/triggers an error when the user creates a listener with a SSL certificate that has an empty CN field16:29
johnsomYeah, we should go back to the standards and see if having no CN at all is valid. I think not.16:30
johnsomWell, it's not CN really, it is the subject field. As there are alternatives to CN16:30
gthiemongehttps://security.stackexchange.com/questions/55414/is-the-common-name-mandatory-for-digital-certificates16:31
opendevreviewTom Weininger proposed openstack/octavia master: Clarify certificate related config options  https://review.opendev.org/c/openstack/octavia/+/90101716:32
johnsomIt looks like there are just two RFCs to parse through16:33
johnsomI can do some digging on this to confirm/deny16:33
gthiemongejohnsom: thanks16:33
johnsomThat said, I have mentioned before, that cert_parser code is not good16:33
gthiemongeyeah I remember that16:35
tweiningI've also been working on setting up certificates and https://review.opendev.org/c/openstack/octavia/+/901017 is the result of some of the trouble I had16:35
tweiningone mistake was probably that I looked at octavia's config options around certs instead of refering to the guide16:36
johnsomYeah, focus on the guide, it is the only source of truth. lol16:36
tweininganyway, gthiemonge and I had a discussion about the agent_server_* options in https://review.opendev.org/c/openstack/octavia/+/901017/7/octavia/common/config.py16:37
tweiningit seems the path is already hardcoded in https://opendev.org/openstack/octavia/src/branch/master/octavia/controller/worker/v2/tasks/compute_tasks.py#L195-L198 so changing the config option would break Octavia?!16:38
gthiemongeIMHO it's purely internal, admins should not change the setting16:38
gthiemongewe should even not mention it in the doc16:39
johnsomCorrect, the ONLY reason those are even in the config definition is we don't have a separate code base for the agent, so it shares the config infrastructure with the controller side. Those are not configurable by admins16:39
johnsomWe didn't until the docs were changed and the /etc/octavia.conf was removed.16:40
gthiemonge:D16:40
gthiemongehttps://opendev.org/openstack/octavia/src/branch/master/octavia/opts.py#L3016:40
tweiningif it really cannot be changed without breaking octavia, we could simply remove it IMO16:40
gthiemongeif we remove this line, they will not be included in the doc, but I don't know the other impacts of this change16:41
tweiningI guess we don't have to decide it now, but we can discuss it in my patch16:41
gthiemongeyep16:41
tweiningthe other question I have is about the guide https://docs.openstack.org/octavia/latest/admin/guides/certificates.html16:42
johnsomWe can break the agent out into it's own repository....16:42
gthiemongeor split config.py into 2 files16:42
johnsomoslo cfg is a global16:43
gthiemongeargh16:43
tweiningthere are the setting [certificates].ca_certificate and [haproxy_amphora].server_ca that get set to the same path. If it's the same setting, why are there two config options?16:43
johnsomSee, the conf that get created automatically and dropped in the config drive sets those. the agent has to share the cfg with the controllers, so it's listed here.16:44
johnsomWhat line in the guide tweining?16:44
gthiemongetweining: in devstack it's not the same path16:44
tweiningUnder "Configuring Octavia"16:44
tweiningpoint 2 and 416:45
gthiemongehttps://opendev.org/openstack/octavia/src/branch/master/devstack/plugin.sh#L432-L43716:45
tweiningah, ok. thanks.16:46
johnsomYeah, in dual CA (don't look at deployment tools like tripleo that do it completely wrong) those are different files16:47
johnsomOh, no, those are the same file, just used in different places16:47
johnsomUgh, I haven't looked at this in a bit.16:48
johnsomThe guide is right16:48
tweiningI guess it is fine. It's just something I noticed an wondered why it is the same path in the guide.16:48
johnsomRight, I remember now, the haproxy_amphora server_ca may need to include intermediate certs, where the usage in [certificates] would not16:50
tweiningone other thing that surprised me a bit was that the defaults for the cert and key path is in https://opendev.org/openstack/octavia/src/branch/master/octavia/certificates/common/local.py /etc/ssl/certs and not /etc/octavia/certs16:50
tweiningbut in my case I intend to override the default using the environment variable16:51
tweininganyway, that is all from me for today I think.16:52
johnsomI think those are only used (if they are) in tests16:52
gthiemongeno idea on this16:52
QGHi ! i have a question about a patch i did : https://review.opendev.org/c/openstack/octavia/+/898803,16:52
QGwhen I run the unit test alone, I don't reproduce the prb  ( octavia.tests.functional.api.v2.test_load_balancer.TestLoadBalancer.test_create_with_vip_subnet_fills_network ) 16:52
johnsomsnakeoil certs are created by the OS at install time. They are bogus self-signed (but valid if you ignore the self signed part)16:53
johnsomMy wonder is if those globals are even used anywhere16:53
gthiemongeQG: you're talking about this error? https://zuul.opendev.org/t/openstack/build/e7e27ff8071140e5a142a5eadd4eee6f16:53
gthiemongeQG: I'll take a look16:54
QGgthiemonge : Yes !16:54
gthiemongethere are some other weird errors16:54
gthiemonge{"faultcode": "Client", "faultstring": "Invalid input for field/attribute vip_network_id. Value: \'<MagicMock name=\'get_network().id\' id=\'139946822340080\'>\'. Value should be UUID format", "debuginfo": null}'16:54
gthiemongeI'm surprised that you don't have it in your nev16:54
gthiemongeenv16:54
gthiemongeanyway, I'll run the tests tomorrow morning16:55
QGgthiemonge: ok thanks !16:55
gthiemongefolks, do you have any other topics for today?16:56
oschwartI wanted to ask quick question about16:56
oschwarthttps://review.opendev.org/c/openstack/octavia-tempest-plugin/+/89306616:56
oschwartif it is too late we can talk about it tomorrow16:56
gthiemongeyou have 4 min oschwart!16:56
oschwarthaha 16:56
oschwart:o16:56
oschwartAfter the latest review, I removed the additional config option here, and after the check pipepline failed, I remembered why we had them in the first place :)16:56
oschwartas stable branches don't have the noop certificate manager16:56
gthiemongeright16:57
gthiemongeI remember that16:57
oschwartshould I revert the patch to have the noop cert option too?16:57
johnsomSo either backport the noop cert manager or gate the tests on the API version16:57
gthiemongejohnsom: you don't agree with this new config option?16:58
johnsomAs I commented, it's really duplicate16:59
gthiemongeFYI I have another meeting in 1min16:59
oschwartlet's talk about it tomorrow then16:59
johnsomIt seems we could backport it16:59
gthiemongelet's close the meeting, I'll check wiht oschwart 16:59
tweining+117:00
gthiemongethank you!17:00
oschwartthanks for the input all17:00
gthiemonge#endmeeting17:00
opendevmeetMeeting ended Wed Nov 15 17:00:12 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:00
opendevmeetMinutes:        https://meetings.opendev.org/meetings/octavia/2023/octavia.2023-11-15-16.00.html17:00
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/octavia/2023/octavia.2023-11-15-16.00.txt17:00
opendevmeetLog:            https://meetings.opendev.org/meetings/octavia/2023/octavia.2023-11-15-16.00.log.html17:00
opendevreviewMichael Johnson proposed openstack/octavia stable/2023.1: Add Noop Certificate Manager  https://review.opendev.org/c/openstack/octavia/+/90099717:01
opendevreviewMichael Johnson proposed openstack/octavia stable/zed: Add Noop Certificate Manager  https://review.opendev.org/c/openstack/octavia/+/90099817:01
opendevreviewMichael Johnson proposed openstack/octavia stable/yoga: Add Noop Certificate Manager  https://review.opendev.org/c/openstack/octavia/+/90099917:01
johnsomClean backports even17:02

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!