Thursday, 2023-01-05

opendevreviewMichal Nasiadka proposed openstack/magnum master: coredns: Add support for Fedora CoreOS 36 and later  https://review.opendev.org/c/openstack/magnum/+/86928608:30
opendevreviewMerged openstack/magnum stable/zed: Support tox4  https://review.opendev.org/c/openstack/magnum/+/86912909:43
opendevreviewMerged openstack/magnum stable/xena: Support tox4  https://review.opendev.org/c/openstack/magnum/+/86917009:43
opendevreviewMerged openstack/magnum stable/yoga: Support tox4  https://review.opendev.org/c/openstack/magnum/+/86917109:43
ShadowJonathanhow can i get magnum-ui to recognise different ingress controllers? when i setup a kolla-ansible stack with magnum and octavia it provides no choices in that field when creating a cluster10:30
ShadowJonathanit makes me think that the ingress controllers aren't properly installed or something, but when i override it with ingress_controller=octavia (for example) it does correctly provision and reach out to octavia to create the load balancers / ingress instances10:31
ShadowJonathan---10:34
ShadowJonathan2: i have also seen that with newer cluster versions (kubernetes v1.22 and above, apparantly) magnum does not properly install its octavia provider into the cluster, it still chooses the v1.8.0 image, even though some cluster versions are way newer than that, resulting in an error that it cannot find a beta version of a resource type. Though, when i upgraded it (manually), i get the following error: 10:34
ShadowJonathanhttps://github.com/kubernetes/cloud-provider-openstack/issues/610. Does magnum correctly check for this? (I have not tried yet, but i want to tell it here regardless as it might be a deeper issue with magnum not really working well with newer kubernetes versions)10:34
ShadowJonathan---10:36
ShadowJonathan3: so far when i've tried to do a "normal" ingress setup with kubernetes, magnum, and octavia, say, a ClusterIP Service being pointed at by an Ingress resource, i got the error that octavia is not able to "look" inside the cluster like that. If i add kuryr to my stack (with kolla-ansible), does octavia and magnum automatically pick up on this, and route this service from the loadbalancer to the ClusterIP 10:36
ShadowJonathanService?10:36
mnasiadka1. I dislike octavia-ingress-controller, I usually use nginx/traefik with Octavia OVN provider (or Amphora) - but not ,,automatically'' deployed via Magnum11:11
mnasiadka2. octavia ingress controller provider? see point 1.11:11
mnasiadka3. Kuryr is not supported, and the support in Kolla-Ansible is not really operational.11:11
ShadowJonathanwould kuryr be a solution for 3 though? or does it not work with kubernetes?12:11
ShadowJonathanalso re-re 1: im talking about having it even show up in magnum-ui, it doesnt, it just shows the "choose an ingress controller" option, and nothing more12:12
ShadowJonathanand tbh i wasnt fishing for opinions, i just wanted to know if these issues are known at all, and not "oh imo we should just let that thing rot", why even push it forward as something supported at all, then?12:13
ShadowJonathanim coming at this from the perspective of a new user, and frankly im trying to evaluate openstack as such, as im doing this as part of an essay/tutorial on how to install openstack with managed kubernetes for my college semester, as it's something that might interest them (currently we have a vmware cluster(f***), and a chaotic free-for-all single kubernetes cluster for multiple semesters), and could help with 12:17
ShadowJonathanmaking students more familar with openstack over commercial clouds like AWS, Azure, or GCP, which the curriculum seems to be heading towards12:17
ShadowJonathanfrom that perspective openstack has a lot of stale introductory documentation, and the little that does exist seems to be outdated and/or requires extra knowledge on the entire system to set it up properly. one of such things thats pushed forward is octavia as a general loadbalancer, and im just asking why some things dont add up, and i hope that its understandable then that a response of "oh, eh, its useless 12:18
ShadowJonathananyways" is not helpful12:18
ShadowJonathanor constructive12:18
opendevreviewMichal Nasiadka proposed openstack/magnum master: coredns: Add support for Fedora CoreOS 36 and later  https://review.opendev.org/c/openstack/magnum/+/86928612:42
opendevreviewMichal Nasiadka proposed openstack/magnum master: coredns: Use /run/systemd/resolve/resolv.conf  https://review.opendev.org/c/openstack/magnum/+/86928614:21
opendevreviewMichal Nasiadka proposed openstack/magnum master: coredns: Use /run/systemd/resolve/resolv.conf  https://review.opendev.org/c/openstack/magnum/+/86928614:30
opendevreviewDale Smith proposed openstack/magnum master: Fix kubelet for Fedora CoreOS 36 to provide real resolvconf to containers.  https://review.opendev.org/c/openstack/magnum/+/86939118:43
daleesmnasiadka: I'm proposing the above as I have been working on this issue too, but have a slightly different solution that affects all `dnsPolicy: default` pods (in Magnum codebase this is only coredns). Changing coredns manifest affects only that single deployment, which is easier to apply to an existing cluster. The kubelet arg version requires18:48
daleescluster rebuilds (or arg changes during an upgrade), but is more general. Thoughts?18:48

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