| mnasiadka | spatel: we're not doing the host part, only the definition of networking in Neutron, see https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/octavia/tasks/prepare.yml | 03:32 |
|---|---|---|
| spatel | mnasiadka hmm | 03:33 |
| spatel | mnasiadka In my case what I should do ? | 03:33 |
| spatel | mnasiadka I have posed question in mailing list - https://paste.opendev.org/show/bUpwFvtZyPC4zZNONBRV/ | 03:34 |
| mnasiadka | spatel: configure the network interfaces on the controllers and let Kolla configure the networking in Neutron? | 03:35 |
| spatel | I have assigned dedicated VLAN 41 for LBaaS management traffic | 03:35 |
| mnasiadka | spatel: is bond0 part of external bridge in OVS? | 03:36 |
| spatel | Yes bond0 is my external neutron interface | 03:36 |
| spatel | all my VMs using bond0 | 03:36 |
| mnasiadka | so you need an ip address on bond0.41 on the controllers to be able to reach amphora VMs (so in the same subnet) | 03:37 |
| spatel | I did assigned IP address on bond0.41 - 192.168.41.1 | 03:38 |
| spatel | I have seeing strange issue, when I remove bond0.41 interface then VM get IP from DHCP and VM can ping DHCP namespace IP (ip netns) | 03:39 |
| spatel | if I create bond0.41 interface then VM stopped pinging DHCP name space | 03:39 |
| mnasiadka | ah, right - then you need to have connectivity to vlan 41 on some other interface - or do what kayobe is doing (create a bridge on bond0, create veth pair there, and use that veth pair to plug into OVS, and move ip address to brbond0.41) | 03:40 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible stable/2023.1: Prevent libvirtd reload when only generating config https://review.opendev.org/c/openstack/kolla-ansible/+/893763 | 03:41 |
| spatel | https://paste.opendev.org/show/bdpDU937A3HHKqUzHA6H/ | 03:41 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible stable/zed: Prevent libvirtd reload when only generating config https://review.opendev.org/c/openstack/kolla-ansible/+/893764 | 03:41 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible stable/yoga: Prevent libvirtd reload when only generating config https://review.opendev.org/c/openstack/kolla-ansible/+/893765 | 03:41 |
| spatel | mnasiadka yes.. I think you are correct, I can't just create bond0.41 on bond0 link. I need to create bridge and attach it to OVS or something | 03:43 |
| spatel | Do you have any short of doc or clue how to do that? | 03:43 |
| spatel | How are we doing that magic with o-hm0 stuff? | 03:44 |
| spatel | I have tired this but it also doesn't work - ovs-vsctl add-port br-int br-lb0 -- set Interface br-lb0 type=internal | 03:46 |
| spatel | just attach port to OVS br-int and assign IP address to br-lb0 but it doesn't work and not able to ping dhcp namespace | 03:47 |
| mnasiadka | o-hm0 uses an OVS port in vxlan network AFAIR, I don't know how ,,production problematic'' is the systemd unit running dhclient | 03:48 |
| spatel | mnasiadka I can live with o-hm0 with tenant network to make it work but not sure its recommended way to use in production or not | 03:49 |
| spatel | currently in my lab I am using o-hm0 with tenant network and life is good. | 03:49 |
| spatel | Now I want to deploy in production so thought use best practice | 03:50 |
| spatel | I found this doc - http://www.panticz.de/octavia/create-ovs-port | 03:50 |
| mnasiadka | as I said, we don't use it in production, if something wrong happens with that dhclient and ovs port tandem, you need to monitor it closely ;) | 03:50 |
| spatel | Look like every doc using o-hm0 for octavia deployment :( | 03:50 |
| spatel | agreed, I don't want to use o-hm0 tenant way to run octavia in production. | 03:52 |
| spatel | Just trying to understand how do I attach octavia interface to OVS | 03:52 |
| spatel | Not able to find any good doc or example | 03:52 |
| spatel | At present everything is working, vm getting IP from DHCP and my dhcp namespace can ping VM. (all I need interface on controller node to attach to OVS and that is where I am stuck) | 03:53 |
| mnasiadka | spatel: well, your bridge is already attached there, it's the ip address on the host level that is making things difficult - so the only good solution here is to create a bridge (brbond0), create a veth pair and use the veth interface as neutron_external_interface | 03:54 |
| mnasiadka | and then you can set the ip address for octavia health manager on brbond0.41 | 03:54 |
| mnasiadka | spatel: maybe our CI role for doing that can help you - https://opendev.org/openstack/kolla-ansible/commit/337771143ba7c392665a14e8aa2434817d9e9473 | 03:55 |
| spatel | I already have neutron_external_interface: br-vlan in that case how do i add second interface to config? are you suggesting neutron_external_interface: br-vlan, brbond0 ? | 03:56 |
| mnasiadka | so, br-vlan has bond0 as a member? | 04:06 |
| spatel | yes | 04:07 |
| spatel | bond0 is my interface and br-vlan is bridge on it | 04:07 |
| spatel | I think I figured out.. let me try and get back to you | 04:14 |
| spatel | mnasiadka found the solution :) and it works | 04:25 |
| spatel | mnasiadka This is what I did and it works - https://paste.opendev.org/show/bRDwUHcHImnMUn9glOCt/ | 04:29 |
| spatel | I wish we can add some kind of reference doc to kolla-ansible document to help our new folks to get some idea how internal wiring works with octavia | 04:31 |
| mnasiadka | spatel: feel free to contribute :) | 04:31 |
| spatel | Sure but its ok to add this snippet in kolla-ansible octavia page? | 04:32 |
| spatel | How would you like to handle it? | 04:32 |
| spatel | Wish we can add this in ansible playbook and set variable in global.yml to execute it | 04:34 |
| mnasiadka | add it somewhere in https://opendev.org/openstack/kolla-ansible/src/branch/master/doc/source/reference/networking/octavia.rst for starters | 04:34 |
| mnasiadka | kolla-ansible never configured host os networking, so I think a guide is enough - that's for kayobe to handle | 04:35 |
| spatel | OK.. let me add snippet here and later we should cook it inside ansible playbook | 04:35 |
| spatel | kayobe itself is different beast :) | 04:36 |
| mnasiadka | spatel: you can add a playbook under contrib/ directory as well | 04:37 |
| spatel | mnasiadka sounds good! let me first get it work right way in my production and then I can add in official doc. | 04:39 |
| spatel | I would see if I can create systemd service to create all these interface and wire them with proper bridge | 04:40 |
| mnasiadka | spatel: it probably would be better to do it in NetworkManager/network-scripts in EL or networkd/whatever else in Debian world | 04:42 |
| spatel | Hmm! I am using netplan for networking so may be that is other way to handle it | 04:43 |
| spatel | mnasiadka question, what is the use of octavia_network_interface: ? | 04:49 |
| spatel | what will happen if I don't specify this variable ? | 04:51 |
| spatel | nevermind, got it.. it use to setup controller_ip_port_list: | 04:55 |
| opendevreview | Michal Nasiadka proposed openstack/kolla stable/yoga: Add comprehensive checks for container restarts https://review.opendev.org/c/openstack/kolla/+/892878 | 05:33 |
| spatel | mnasiadka hey what is octavia-driver-agent container for? | 05:44 |
| spatel | I haven't seen it before | 05:44 |
| mnasiadka | spatel: for other drivers than amphora (e.g. ovn) | 05:47 |
| spatel | oh so for OVN we need that container correct? | 05:47 |
| mnasiadka | yes | 05:48 |
| spatel | cool | 05:48 |
| opendevreview | Merged openstack/kolla master: Document KOLLA_UPGRADE_CHECK environment variable https://review.opendev.org/c/openstack/kolla/+/893484 | 05:49 |
| opendevreview | Michal Nasiadka proposed openstack/kolla stable/xena: Add comprehensive checks for container restarts https://review.opendev.org/c/openstack/kolla/+/893766 | 07:07 |
| opendevreview | Merged openstack/kolla master: Improve kolla-toolbox offline support. https://review.opendev.org/c/openstack/kolla/+/884368 | 07:21 |
| opendevreview | Natz cheng proposed openstack/kolla-ansible master: Updated links in documentation to be safe links https://review.opendev.org/c/openstack/kolla-ansible/+/893836 | 07:51 |
| opendevreview | Natz cheng proposed openstack/kolla master: Updated links in documentation to be safe links https://review.opendev.org/c/openstack/kolla/+/893838 | 07:58 |
| opendevreview | Maksim Malchuk proposed openstack/kolla-ansible stable/xena: CI: completely drop upgrade jobs https://review.opendev.org/c/openstack/kolla-ansible/+/893796 | 08:12 |
| mmalchuk | mnasiadka is it ok now? completely drop upgrade jobs? | 08:13 |
| opendevreview | Maksim Malchuk proposed openstack/kolla-ansible stable/xena: Use better default bind address for ironic-tftp https://review.opendev.org/c/openstack/kolla-ansible/+/893422 | 08:16 |
| mnasiadka | mmalchuk: commented | 08:18 |
| opendevreview | Merged openstack/kolla stable/2023.1: Add comprehensive checks for container restarts https://review.opendev.org/c/openstack/kolla/+/892876 | 08:19 |
| opendevreview | Michal Arbet proposed openstack/kolla-ansible master: [DNM] Just test something https://review.opendev.org/c/openstack/kolla-ansible/+/893609 | 08:19 |
| opendevreview | Natz cheng proposed openstack/kolla master: Use py3 as the default runtime for tox https://review.opendev.org/c/openstack/kolla/+/893840 | 08:26 |
| opendevreview | Maksim Malchuk proposed openstack/kolla-ansible stable/xena: CI: Completely drop upgrade jobs from EOL Wallaby https://review.opendev.org/c/openstack/kolla-ansible/+/893796 | 08:28 |
| opendevreview | Maksim Malchuk proposed openstack/kolla-ansible stable/xena: Use better default bind address for ironic-tftp https://review.opendev.org/c/openstack/kolla-ansible/+/893422 | 08:28 |
| mmalchuk | mnasiadka done | 08:28 |
| mmalchuk | mnasiadka could you also review gnocchi, its back : https://review.opendev.org/q/I3ca4e10508c26b752412789502ceb917ecb4dbeb | 08:34 |
| opendevreview | Merged openstack/kolla-ansible stable/yoga: Added precheck for OpenSearch migration https://review.opendev.org/c/openstack/kolla-ansible/+/893172 | 08:43 |
| kevko | mnasiadka: i found the issue with aarch64 podman | 08:44 |
| mnasiadka | kevko: fantastic, how bad is it? | 08:45 |
| mmalchuk | great work | 08:51 |
| mmalchuk | say it | 08:52 |
| kevko | well, i am not sure why volumes are created under root:root | 08:55 |
| kevko | while on debian nonaarch64 it is fluentd:kolla | 08:55 |
| kevko | *with root:root perms | 08:56 |
| opendevreview | Merged openstack/kolla master: openstack-base: add block for overriding global upper constraints https://review.opendev.org/c/openstack/kolla/+/893608 | 08:59 |
| kevko | i also don't understand why volume is fluentd:kolla if user in fluentd is td-agent | 09:01 |
| kevko | okay, now i got it ..i think we need to specify permissions for volume | 09:08 |
| kevko | let me try something | 09:26 |
| opendevreview | Maksim Malchuk proposed openstack/kolla stable/2023.1: Improve kolla-toolbox offline support. https://review.opendev.org/c/openstack/kolla/+/893849 | 09:26 |
| opendevreview | Maksim Malchuk proposed openstack/kolla stable/zed: Improve kolla-toolbox offline support. https://review.opendev.org/c/openstack/kolla/+/893851 | 09:31 |
| opendevreview | Maksim Malchuk proposed openstack/kolla stable/yoga: Improve kolla-toolbox offline support. https://review.opendev.org/c/openstack/kolla/+/893852 | 09:31 |
| Fl1nt | Hi guys | 09:33 |
| Fl1nt | so, we do have an issue with this patch: https://review.opendev.org/c/openstack/kolla-ansible/+/878270 | 09:33 |
| Fl1nt | I've someone that keeps asking for the same question each round | 09:33 |
| Fl1nt | I do suspect this reviewer isn't using designate | 09:34 |
| Fl1nt | so how could we prevent such infinite back and forth on reviews? | 09:34 |
| mnasiadka | Please discuss that on the meeting, it's the venue for this. | 09:34 |
| Fl1nt | Can't make it at meeting times | 09:34 |
| opendevreview | Maksim Malchuk proposed openstack/kolla stable/xena: Improve kolla-toolbox offline support. https://review.opendev.org/c/openstack/kolla/+/893854 | 09:35 |
| Fl1nt | I'm already having a meeting at community meeting time. | 09:35 |
| opendevreview | Michal Arbet proposed openstack/kolla-ansible master: [DNM] Just test something https://review.opendev.org/c/openstack/kolla-ansible/+/893609 | 09:36 |
| Fl1nt | TBN: without this patch, the one that was merged: https://review.opendev.org/c/openstack/kolla-ansible/+/878063 will not work properly. | 09:36 |
| mnasiadka | Fl1nt: fine by me, do the discussion in Gerrit then | 09:39 |
| mnasiadka | Fl1nt: basically reviewers are pointing to the fact, it's not backwards compatible - and we can't break existing deployments in happy camper style. | 09:40 |
| Fl1nt | How is there so many break from wallaby to xena that happened and then we can't fix a role that was improperly implemented? Designate simply just doesn't work in its current form. | 09:41 |
| Fl1nt | any upgrade of kolla do have breaking changes by nature. | 09:41 |
| frickler | designate works perfectly fine in my deployment | 09:42 |
| Fl1nt | frickler, how do you use it? Do you use it as DNSaaS with Openstack services native integration? Do you use it as DNSaaS solution only as public DNS provider? Do you use it with external delegation? Or are you just using it to publish FIP FQDN? | 09:45 |
| Fl1nt | First of all, FIP FQDN can't work out of the box as neutron do not use the proper credentials to talk to designate API, so you can't get FIP FQDN to create automatically within designate without sink and notification topics, same things for automatic PTR creation and deletion, when trying to delete the FIP neutron just simply can't instruct designate to delete the recordset. | 09:47 |
| Fl1nt | Then by default the pools do use external IPs to instruct mDNS to update the DNS server which should not happens out of externally managed zones. | 09:48 |
| Fl1nt | etc | 09:48 |
| Fl1nt | out of the simplest DNSaaS scenario nothing works out of the box. | 09:49 |
| frickler | well it all works for me including records for FIPs | 09:49 |
| Fl1nt | so you're the only one not affected by the reported bugs. | 09:50 |
| Fl1nt | it can't work as kolla do not implement the role the way the upstream project intend it to be implemented. | 09:50 |
| frickler | I'm also involved in designate upstream, so I doubt that to be true, either | 09:51 |
| Fl1nt | ok fine, so everyone reporting bugs with kolla implementation is having it wrong right? | 09:52 |
| frickler | all the bugs you reference are either incomplete or resolved according to what I see | 09:52 |
| Fl1nt | no they're not, this one is from the mDNS being improperly set on default kolla pool: https://bugs.launchpad.net/kolla-ansible/+bug/1773972 for instance. This one https://bugs.launchpad.net/kolla-ansible/+bug/1879557 is marked as fixed because I did fixed it but the fix can't work without the bigger patch. This one can't work as it needs multiple pools support on kolla that we currently don't have: | 09:57 |
| Fl1nt | https://bugs.launchpad.net/kolla-ansible/+bug/2008691. https://bugs.launchpad.net/kolla-ansible/+bug/2012292 this one is due to the way kolla improperly manage the pools.yaml file structure expected by designate-manage. etc | 09:57 |
| frickler | did you even look at what I wrote on those bugs earlier? | 09:58 |
| Fl1nt | yes, why? | 09:58 |
| frickler | because without logs, how do you know what is actually wrong in https://bugs.launchpad.net/kolla-ansible/+bug/1773972 for example? | 09:59 |
| frickler | why do you keep denying that overriding pools.yaml with your own file isn't a valid, existing, implemented solution? | 09:59 |
| Fl1nt | Because I've the exact same issue! I did create the patchset because I hitted every single listed bug report issue, I did deployed the role using plain fresh and vanilla configuration on a multinode deployment and it just don't work. | 10:00 |
| Fl1nt | frickler, it doesn't work | 10:01 |
| frickler | you may have an issue that looks the same, doesn't have to be identical. please create a bug reports with the relevant logs and configs, and we can discuss what is going wrong there | 10:01 |
| Fl1nt | I'll just abandon the patchset... | 10:03 |
| opendevreview | Gaël THEROND proposed openstack/kolla-ansible master: Revert "Fix improper designate-manage command usage." https://review.opendev.org/c/openstack/kolla-ansible/+/893769 | 10:07 |
| opendevreview | Merged openstack/kolla-ansible master: ovn: Improve clustering https://review.opendev.org/c/openstack/kolla-ansible/+/868929 | 10:08 |
| opendevreview | Merged openstack/kolla-ansible stable/yoga: Add documentation for migrating from CS8 to RL9 https://review.opendev.org/c/openstack/kolla-ansible/+/884858 | 10:08 |
| opendevreview | Merged openstack/kolla stable/2023.1: Add server-status handler to Rocky/Centos Apache conf https://review.opendev.org/c/openstack/kolla/+/893220 | 10:08 |
| opendevreview | Merged openstack/kolla stable/zed: Add server-status handler to Rocky/Centos Apache conf https://review.opendev.org/c/openstack/kolla/+/893241 | 10:08 |
| opendevreview | Merged openstack/kolla stable/yoga: Add server-status handler to Rocky/Centos Apache conf https://review.opendev.org/c/openstack/kolla/+/893242 | 10:08 |
| opendevreview | Verification of a change to openstack/kolla stable/xena failed: Add server-status handler to Rocky/Centos Apache conf https://review.opendev.org/c/openstack/kolla/+/893243 | 10:08 |
| kevko | I agree with Fl1nt, vanilla configuration not working | 10:09 |
| kevko | for example we need to config override domain name in neutron config ...and we have to provide pools.yaml | 10:10 |
| jangutter | .... so would now be an awkward time to ask how to go about testing a major refactor of a role? (etcd) https://review.opendev.org/c/openstack/kolla-ansible/+/888012 | 10:10 |
| kevko | frickler: Fl1nt just gave us an option to configure kolla-ansible and let kolla render configs | 10:11 |
| kevko | (with that fix) | 10:11 |
| jangutter | kevko: but I think it's usually more preferable to keep the code inside kolla-ansible simple, and use drop-in config for this. | 10:11 |
| SvenKieske | jangutter: xD | 10:11 |
| kevko | jangutter: simple and not working ? | 10:12 |
| kevko | jangutter: Fl1nt patch is simple and working | 10:12 |
| SvenKieske | most of the designate changes seemed fine to me, that is, providing better defaults. the problem imho is that not all usecases are present in this approach and there's a mixup - imho - between "publicly" available dns servers (which don't need to be "public", only "reachable", as frickler put it) | 10:13 |
| opendevreview | Merged openstack/kolla-ansible stable/zed: Drop useless DUMMY_ENVIRONMENT environment for cron container https://review.opendev.org/c/openstack/kolla-ansible/+/893209 | 10:15 |
| SvenKieske | so I like the new templated pool yaml, it's imho much easier to tweak this way. | 10:15 |
| kevko | and this is how we lose contributors :( | 10:15 |
| kevko | SvenKieske it is not NEW templated pools.yaml ...it's is fixed :D | 10:16 |
| SvenKieske | I guess both sides could do a slightly better job at communication here :) and the change is rather large, which is an issue on it's own. I spent much time reviewing this and still do, and I overlooked the public api being used for mdns axfr, which is really not a good design. | 10:17 |
| opendevreview | Merged openstack/kolla-ansible stable/yoga: Drop useless DUMMY_ENVIRONMENT environment for cron container https://review.opendev.org/c/openstack/kolla-ansible/+/893210 | 10:18 |
| opendevreview | Merged openstack/kolla-ansible stable/2023.1: Drop useless DUMMY_ENVIRONMENT environment for cron container https://review.opendev.org/c/openstack/kolla-ansible/+/893208 | 10:18 |
| opendevreview | Merged openstack/kolla-ansible stable/xena: CI: Completely drop upgrade jobs from EOL Wallaby https://review.opendev.org/c/openstack/kolla-ansible/+/893796 | 10:18 |
| opendevreview | Merged openstack/kolla stable/2023.1: docs: we moved UNBUILDABLE_IMAGES to separate file https://review.opendev.org/c/openstack/kolla/+/892410 | 10:18 |
| SvenKieske | just because some setups might be fine with exposing mdns publicly it's not good to expose it by default for this scenario. there's a misunderstanding, that yes: mdns needs to reach the dns server via AXFR, but that can be done more securely by using e.g. a VPN, it should imho not be done via public inet | 10:18 |
| opendevreview | Merged openstack/kolla stable/zed: docs: we moved UNBUILDABLE_IMAGES to separate file https://review.opendev.org/c/openstack/kolla/+/892411 | 10:18 |
| kevko | it's not large ... | 10:19 |
| SvenKieske | I still think designate needs to be burned down and should be rebuilt with a sane architecture, but I guess I can't have nice things ;) | 10:19 |
| SvenKieske | it's +299 -113 lines, so all in all 412 lines to review, at least, without considering context lines needed. so almost 500 lines. I'd consider this large. | 10:20 |
| SvenKieske | tbf there are some comments in there. yes I've seen larger changesets (looking at podman), but they tend to get worse, not better, with more lines. | 10:21 |
| SvenKieske | when the number of lines in a changeset approaches 1000 the probability that a bug is not catched during review approaches 1. | 10:22 |
| SvenKieske | that's a quote adapted from "The odds of deployment failure approach 100% as the number of distinct change sets approaches seven." from: https://lwn.net/Articles/562333/ | 10:23 |
| mmalchuk | you propose to split change to several reviews? | 10:29 |
| SvenKieske | frickler did. I'm hesitant, because this has been worked on for a long time. It would've been better if this was brought up earlier (I think it wasn't? But I'm not sure). But it seems we have already lost this contributor. | 10:31 |
| SvenKieske | from a purity perspective it should really be done in separate changes, as indicated by the commit message. because imho a single commit should fix a single bug, not 5 (or whatever the number is) | 10:32 |
| mmalchuk | I agree with kevko, I'm also still have changes in gerrit with 2+ years on review | 10:32 |
| mmalchuk | https://review.opendev.org/c/openstack/kayobe/+/793697 | 10:33 |
| mmalchuk | for example | 10:33 |
| SvenKieske | a single changeset should do a single atomic thing. imho this can be ignored for trivial fixes, which might get rolled up. but the dns stuff is really not trivial. but this is a rather theoretical perspective and we also already have other huge changesets. | 10:33 |
| SvenKieske | we should strive to apply "rules" like these to all patchsets. | 10:33 |
| mmalchuk | the same issue... years ago there was 2 patchsets, then they were merged, then again shomeone ask to split | 10:34 |
| SvenKieske | mmalchuk: I feel your pain, I guess my first kolla change needed a year or so to get merged and there where constant changes being demanded. I also was close to giving up. So I really understand the perspective of new contributors, I think. | 10:34 |
| mmalchuk | I'm still here | 10:35 |
| mmalchuk | and try to push it | 10:35 |
| SvenKieske | well, me too, somehow :D | 10:35 |
| mmalchuk | lets help Fl1nt | 10:35 |
| SvenKieske | so I really feel we should make it easier to contribute. if we want to enforce rules around changeset size that should be done immediately on patch submission or even before. | 10:36 |
| SvenKieske | so people don't invest much time, and are then being told to rework everything. | 10:36 |
| SvenKieske | just looked it up, my first patch took from october 2020 until march 2022 | 10:38 |
| mmalchuk | the change were abandoned and he leave irc | 10:41 |
| mmalchuk | what can we do? | 10:41 |
| frickler | look at the bugs, try to reproduce the issue(s), make them actionable | 10:42 |
| kevko | SvenKieske: from 500 lines, the bigger half ot that lines are docs :D ... so implementation is much much less | 10:42 |
| SvenKieske | kevko: sure, but the implementation does many different things at once. I had a fair share of questions on that merge request as well, just to really understand what was being done, because the submitted docs where also not very clear at the start. | 10:43 |
| SvenKieske | and I also agree with frickler, that the bug reports, at least in part, where not really saying much what even was the problem | 10:44 |
| SvenKieske | e.g. https://bugs.launchpad.net/kolla-ansible/+bug/1773972 | 10:44 |
| kevko | kevko: many different things at once ? you meant it's fixing several not properly implemented mixed DNS stuff in designate role | 10:45 |
| SvenKieske | it has been some time, but last time I deployed this, it did work. so it would be really good to show what's actually broken, in the bug report. yes, that is a lot of work. | 10:45 |
| kevko | which is not working | 10:45 |
| kevko | SvenKieske: you probably had a simple ENV | 10:45 |
| SvenKieske | kevko: really it's nuanced: you can deploy designate in like at least 4 different scenarios, some of those don't work with kolla, like e.g. we only provide the bind9 backend. | 10:46 |
| kevko | SvenKieske: did you use neutron dns and designate dnaas together ? | 10:46 |
| SvenKieske | it's not helpful to declare something "completely broken" when it works for some usecases. | 10:46 |
| kevko | It's also lucky that we have downstream git that we use instead of upstream and we have cherry-picked things that have been sitting for review for years and it works for us for several versions :) | 10:48 |
| kevko | so, if we don't want to merge ...nevermind ..i've took that patches and we are using in downstream without problem :) | 10:49 |
| SvenKieske | kevko: you have the same imprecise language as Flint imho. what does your question even mean? designate integration into neutron has several subfeatures which don't need to be used all at once, see: https://docs.openstack.org/designate/latest/user/neutron-integration.html so I'm not sure what I should answer to such broad questions, really. | 10:49 |
| SvenKieske | e.g. I did use neutron dns to provide automatic FQDN for hardware deployed by ironic. | 10:50 |
| SvenKieske | in general I like most of the rework of what flint did, I'd maybe rearrange some stuff, but I don't have the time for that, currently. So I would not oppose to merge this just based on the size of the changeset. | 10:51 |
| SvenKieske | the one thing I'd definitely change is the exposition of mdns, because people can imho shoot themselves in the foot there from a security perspective. | 10:52 |
| mmalchuk | folks, please +W https://review.opendev.org/q/Iae8a937bb2c35d2eb83e2c4522d829a6cfe25f0d | 10:53 |
| kevko | we have release notes for changes ... | 10:53 |
| SvenKieske | kevko: I'm not sure, who are you replying too? | 10:54 |
| mmalchuk | mnasiadka this https://review.opendev.org/c/openstack/kolla-ansible/+/893250 should be abandoned | 10:54 |
| mnasiadka | mmalchuk: are you sure? your comment is a bit contradictory ;) | 10:55 |
| mmalchuk | sure | 10:55 |
| mmalchuk | issue introduced in zed | 10:56 |
| SvenKieske | I was just rereading that..yeah so is the bug present there, or not? | 10:56 |
| SvenKieske | so not, it seems, fine then. | 10:56 |
| SvenKieske | at least this project still has contributors you can argue with, not like some other projects who are rather abandoned.. oO | 10:57 |
| mmalchuk | mnasiadka removed +1 from change) sorry... | 10:59 |
| kevko | I've been arguing more and more lately | 11:00 |
| mnasiadka | well, basically we need to have in mind that even if something is configured wrong atm in kolla-ansible, we need to have a path for users from point A to point B, not just claim this was broken, we fixed it, but now you need to reconfigure your whole designate approach | 11:03 |
| mmalchuk | so, mnasiadka you agree to drop this huge change? | 11:05 |
| mmalchuk | almost 'huge' as kevko said) | 11:06 |
| mnasiadka | Whatever the author wants, I agree we could support direct Neutron/Nova integration - but we should introduce that as an alternative (under some variable or something) and then deprecate the old approach | 11:06 |
| mnasiadka | (if needs deprecating) | 11:06 |
| opendevreview | Michal Arbet proposed openstack/kolla-ansible master: [DNM] Just test something https://review.opendev.org/c/openstack/kolla-ansible/+/893609 | 11:06 |
| mmalchuk | who will do that? authore leaves | 11:06 |
| kevko | mnasiadka: if it is broken in kolla out-of-the box .. so it just means that majority of people using designate role is using config overrides ...so if we fix kolla ..they are ok ..they are using own config ... | 11:13 |
| kevko | for others witsh simpler config nothing will change ..just add reno that some vars need to be amended in kolla-ansible | 11:14 |
| mmalchuk | +1 | 11:16 |
| opendevreview | Merged openstack/kolla-ansible stable/zed: Fixes WEBSSO_KEYSTONE_URL Value https://review.opendev.org/c/openstack/kolla-ansible/+/893213 | 11:17 |
| opendevreview | Merged openstack/kolla-ansible stable/2023.1: Fixes WEBSSO_KEYSTONE_URL Value https://review.opendev.org/c/openstack/kolla-ansible/+/893212 | 11:24 |
| frickler | kevko: if it was broken out of the box, the CI would not work. if the CI is testing the wrong scenario in your opinion, start fixing that first. otherweise stop claiming it doesn't work when the CI says something different | 11:27 |
| kevko | frickler: challenge accepted ..i will add to my todolist :) | 11:29 |
| mmalchuk | frickler CI didn't check everything | 11:32 |
| mmalchuk | it test simple scenario, not used by most people in production | 11:32 |
| kevko | +1 | 11:34 |
| mmalchuk | mnasiadka lets build gnocchi : https://review.opendev.org/q/I3ca4e10508c26b752412789502ceb917ecb4dbeb | 11:48 |
| mnasiadka | kevko: as long as my pools.yaml is unchanged after this patch (and I don’t need to change any config) - I’m happy | 11:51 |
| mnasiadka | Rewriting config from one var to another is not my type of sport | 11:52 |
| mnasiadka | We can discuss that on the meeting | 11:53 |
| opendevreview | Michal Arbet proposed openstack/kolla-ansible master: [DNM] Just test something https://review.opendev.org/c/openstack/kolla-ansible/+/893609 | 12:14 |
| mnasiadka | mgoddard mnasiadka hrw bbezak frickler kevko SvenKieske mmalchuk gkoper jangutter jsuazo - meeting in 9 minutes | 12:51 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible stable/2023.1: ovn: Improve clustering https://review.opendev.org/c/openstack/kolla-ansible/+/893770 | 12:57 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible stable/zed: ovn: Improve clustering https://review.opendev.org/c/openstack/kolla-ansible/+/893771 | 12:57 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible stable/yoga: ovn: Improve clustering https://review.opendev.org/c/openstack/kolla-ansible/+/893772 | 12:58 |
| SvenKieske | I'm always amazed how a changes is being worked on for 8 months and then reviewed and merged in under two hours :) https://review.opendev.org/c/openstack/kolla-ansible/+/868929 | 13:00 |
| mnasiadka | #startmeeting kolla | 13:01 |
| opendevmeet | Meeting started Wed Sep 6 13:01:26 2023 UTC and is due to finish in 60 minutes. The chair is mnasiadka. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:01 |
| opendevmeet | The meeting name has been set to 'kolla' | 13:01 |
| mnasiadka | #topic rollcall | 13:01 |
| mnasiadka | o/ | 13:01 |
| frickler | \o | 13:01 |
| jangutter | o/ | 13:01 |
| mhiner | o/ | 13:02 |
| SvenKieske | \o/ | 13:02 |
| SvenKieske | o/ | 13:02 |
| mnasiadka | SvenKieske: well, it has been reviewed multiple times, it's just that this bug got a lot of attention in my company downstream ;) | 13:02 |
| SvenKieske | sure, but I'm getting robbed of my +1 stats ;) | 13:02 |
| mnasiadka | #topic agenda | 13:03 |
| mnasiadka | * CI status | 13:03 |
| mnasiadka | * Release tasks | 13:03 |
| mnasiadka | * Regular stable releases (first meeting in a month) | 13:03 |
| mnasiadka | * Current cycle planning | 13:03 |
| mnasiadka | * Additional agenda (from whiteboard) | 13:03 |
| mnasiadka | * Open discussion | 13:03 |
| mnasiadka | #topic CI status | 13:03 |
| mnasiadka | So, let's see | 13:03 |
| mmalchuk | o/ | 13:03 |
| SvenKieske | there was the rocky infra breakage, but that's fixed, right? | 13:04 |
| mnasiadka | deleted wallaby from EM branch status | 13:04 |
| mnasiadka | since it's EOL | 13:04 |
| mnasiadka | yes, it was rocky infra breakage | 13:04 |
| frickler | do we need to mirror more repos? | 13:04 |
| mnasiadka | well, rocky is not mirrored at all | 13:06 |
| mmalchuk | there was not only rocky issue | 13:06 |
| mnasiadka | second thing is we could mirror docker rpm from something that has smaller size | 13:06 |
| mmalchuk | also docker and two more | 13:06 |
| mnasiadka | grafana is also usually broken every now and then | 13:06 |
| mmalchuk | yep. docker and grafana | 13:06 |
| mnasiadka | frickler: I was thinking on working on docker, just need to find proper place in system-config for that | 13:07 |
| frickler | mnasiadka: let me know if you need help, though I'd have to search for that myself | 13:08 |
| mnasiadka | frickler: there's mirror-update role that uses rsync, I doubt docker exposes rsync | 13:08 |
| mnasiadka | I'll have a look and start asking stupid questions on #opendev :) | 13:09 |
| frickler | mnasiadka: ah, right. I don't know if there is a different solution for rpms | 13:09 |
| frickler | we could by starting to mirror docker .debs though ;) | 13:09 |
| mnasiadka | frickler: we do mirror them I think, we just don't use them in kolla | 13:09 |
| frickler | hmm, o.k. | 13:10 |
| bbezak | o/ | 13:10 |
| mnasiadka | hmm, zed rocky9/debian periodics failed | 13:10 |
| mnasiadka | #link https://zuul.openstack.org/builds?project=openstack%2Fkolla&pipeline=periodic&skip=0 | 13:11 |
| opendevreview | Michal Arbet proposed openstack/kolla-ansible master: [DNM] Just test something https://review.opendev.org/c/openstack/kolla-ansible/+/893609 | 13:11 |
| opendevreview | Merged openstack/kolla stable/xena: Add server-status handler to Rocky/Centos Apache conf https://review.opendev.org/c/openstack/kolla/+/893243 | 13:11 |
| frickler | I also noticed there seem to still be rmq errors, like the latest failure in https://review.opendev.org/c/openstack/kolla/+/893722 | 13:11 |
| jsuazo | o/ | 13:11 |
| SvenKieske | kolla-publish-ubuntu-quay seems also to have issues? | 13:11 |
| mnasiadka | SvenKieske: on zed? I don't think so | 13:13 |
| mnasiadka | ok, let's move on and see if it fails again | 13:13 |
| mnasiadka | #topic Release tasks | 13:13 |
| mnasiadka | So, this week we should post a patch with release highlights | 13:13 |
| SvenKieske | it has stats here at least: https://grafana.opendev.org/d/c0d59dad13/kolla-failure-rate?orgId=1 | 13:14 |
| mnasiadka | Anybody wants to have a go at skimming what we could post as marketing highlights? | 13:14 |
| mnasiadka | scanning release notes is my usual go | 13:14 |
| mnasiadka | SvenKieske: that dashboards surely needs love | 13:14 |
| SvenKieske | I fixed what I knew how to fix | 13:15 |
| SvenKieske | I still need to check what versions we can bump, but I guess it's not that much | 13:15 |
| mnasiadka | bbezak: want to have a go at release highlights? | 13:15 |
| mnasiadka | SvenKieske: the whole prometheus stack would be happy :) | 13:16 |
| mnasiadka | ok, I'll do the release highlights :) | 13:17 |
| mnasiadka | So, when we are at highlights | 13:17 |
| SvenKieske | ah right, that are easy bumps, most of the time, did it in the past already | 13:17 |
| mnasiadka | one thing is Let's Encrypt | 13:17 |
| mnasiadka | kevko: did you update that Kolla patch already? | 13:17 |
| mnasiadka | seems not | 13:18 |
| mnasiadka | would be nice to get it rolling sooner than later | 13:18 |
| mnasiadka | second thing is Podman | 13:18 |
| mnasiadka | mhiner: I assume you still have some arm related issues (but I think kevko is looking at them)? | 13:19 |
| mhiner | yes, I am also trying to solve it but didnt have much time for that since the last meeting | 13:19 |
| SvenKieske | here are also some unadressed podman comments left to do: https://review.opendev.org/c/openstack/ansible-collection-kolla/+/852240 | 13:19 |
| mnasiadka | I see https://review.opendev.org/c/openstack/kolla-ansible/+/893187 is an easy one | 13:20 |
| mnasiadka | SvenKieske: that one - I'm still puzzled why we need ternary and why it doesn't work the same way as for docker role? | 13:21 |
| mhiner | SvenKieske: I guess the debian repo comments can be closed and Im waiting on another opinion regarding the podman containers starting/restarting | 13:21 |
| SvenKieske | I'm not sure on this ternary stuff. mhiner tested it and said it didn't work | 13:22 |
| kevko | mnasiadka: didn't have a time :( ...but i have it half reworked regarding kolla part | 13:22 |
| SvenKieske | if we had the time it would be cool to just use always venvs and be done with this ;) | 13:23 |
| mnasiadka | kevko: great, hopefully you will have time to finish it off ;) | 13:23 |
| kevko | i am experimenting with podman on zuul ... i have some indices ..but still not confirmed | 13:23 |
| mhiner | it didnt work because the variable were set, but works when they are commented out like in https://review.opendev.org/c/openstack/ansible-collection-kolla/+/892990 | 13:23 |
| mnasiadka | ok, I commented on the ansible-collection-kolla patch - sorry, but let's keep the changes only podman related | 13:23 |
| mnasiadka | if you need to change anything in the docker role (and I don't know why would you) - it should be a separate patchset | 13:24 |
| ihalomi | mnasiadka: its more like refactor since you pointed bad manners in code in podman patchset that were just copied from docker roles | 13:24 |
| kevko | btw, it would be nice to merge kolla part of podman | 13:24 |
| mnasiadka | I pointed bad manners? I'm fine with copying bad manners :) | 13:25 |
| mnasiadka | kevko: I promised to have a look, should have time on Friday | 13:25 |
| SvenKieske | well that's the consequence if you want to have the same code patterns everywhere, of course you have then unrelated refactors..that's quite some circular logic here.. | 13:25 |
| kevko | because now when i needed to add cross-dependency from kolla-ansible -> kolla .... setup_gate is failing because kolla master don't know how to work with podman ... because not merged | 13:25 |
| ihalomi | mnasiadka: not directly you :D but you as reviewers :) | 13:25 |
| mnasiadka | SvenKieske: well, adding new functionality should be separate from refactoring - it's a bit insane to do it in one step | 13:25 |
| mnasiadka | refactor is refactor - it's not adding new functionality | 13:26 |
| SvenKieske | not really, it's insane to replicate known wrong behaviour just because "we have done it this way since forever" | 13:26 |
| mnasiadka | well, usually you do a refactor first, and then add new functionality on top of it | 13:26 |
| kevko | +1 | 13:27 |
| mnasiadka | I just value small patchsets that do one thing, not change everything at the same time - because we have no clue what is old, what is new, how should it work, etc | 13:27 |
| SvenKieske | yeah, this way you never refactor, because people with money always only pay for features, but not refactoring, so we end up where we are, old stuff rotting. | 13:27 |
| SvenKieske | I see maybe 1% of commits doing refactoring and 99% being feature work, where it should be the reverse. these numbers are made up of course. | 13:28 |
| mnasiadka | I don't know any people with money that want to invest in Kolla :) | 13:28 |
| SvenKieske | really? who's paying you then? ;) | 13:28 |
| kevko | +1 :D | 13:28 |
| mnasiadka | and this is rather a sidetracking thread, we told Konstantin to refactor a lot of stuff in Kolla in order to add support for Podman, so we shouldn't change approaches for the same feature set in another role | 13:29 |
| SvenKieske | sorry for the rant, but it's still circular logic: people say: "don' | 13:29 |
| Fl1nt | mnasiadka, my company invest on our team that work with kolla and try to fix things when it break, they're paying time we pass on those patch. | 13:29 |
| mnasiadka | SvenKieske: I know you're a fan of ranting, I'm Polish - we rant even when we sleep :) | 13:29 |
| SvenKieske | t do this -> people change their code -> now it's done differently than in an unrelated file -> separate your refactoring from feature work.. | 13:29 |
| *** hrww is now known as hrw | 13:29 | |
| mmalchuk | Fl1nt me too | 13:30 |
| SvenKieske | honestly all these issues in the last few weeks are always because we have no written down thing we all agreed upon, no? | 13:30 |
| Fl1nt | Here are my two cents | 13:30 |
| Fl1nt | since a while now | 13:31 |
| mnasiadka | Can we have those two cents in Open discussion section? | 13:31 |
| mnasiadka | not now? | 13:31 |
| Fl1nt | sure | 13:31 |
| mnasiadka | thanks | 13:31 |
| SvenKieske | so we are always arguing in circles, "do we need a release note for this?" "is this refactoring"? "should this patch be split up"? There should be no argument about this stuff during code review imho, it should be clear from coding guidelines or a linter. | 13:31 |
| mnasiadka | mhiner: let's discuss the a-c-k change in Gerrit, I'll try to do some testing and help with the code | 13:31 |
| * SvenKieske will shut up for now :) | 13:31 | |
| mnasiadka | #topic Regular stable releases (first meeting in a month) | 13:32 |
| kevko | SvenKieske: feel free to write detailed developer docs and we can agree all together in review | 13:32 |
| mnasiadka | frickler: we should wait until the OVN clustering backports are merged, so let's revisit next week (I maybe wrongly assumed you'll want to do the releases) | 13:32 |
| frickler | I think we should just stop doing stable releases | 13:33 |
| mnasiadka | SvenKieske: yes, channel your ranting powers to a document and Gerrit patchset | 13:33 |
| mmalchuk | mnasiadka can I add Xena backport of OVN? | 13:33 |
| mnasiadka | frickler: at all? | 13:33 |
| frickler | they've become so irregular nobody can rely on them anyway | 13:33 |
| mnasiadka | mmalchuk: sure | 13:33 |
| frickler | yes | 13:33 |
| Fl1nt | just use tags | 13:34 |
| mmalchuk | mnasiadka ok. it take some time to solve conflicts | 13:34 |
| mnasiadka | frickler: so one release and we're done? this is also a bit weird for people still using pypi for kolla releases | 13:34 |
| SvenKieske | I'll try, that will be a fun review I'm sure :) | 13:34 |
| frickler | well tags are releases for us | 13:34 |
| frickler | stop publishing to pypi, too. issue solved | 13:34 |
| mnasiadka | well, that was something I proposed on one PTG, nobody agreed :) | 13:35 |
| Fl1nt | TBH, we do only use tags are they ensure readability, discoverability and reproducibility (ish) | 13:35 |
| SvenKieske | I agree, but does this need to be announced, for release engineering etc? I'm not sure on the openstack process here | 13:35 |
| frickler | I think deployment project are special in that regard | 13:35 |
| mnasiadka | #link https://releases.openstack.org/reference/release_models.html | 13:35 |
| mnasiadka | those are the release models we can use | 13:35 |
| SvenKieske | tags are nice, but the packages on pypi let people assume these are fresh, when they really are not | 13:35 |
| frickler | but I can try to find out. also I agree that that should be a PTG decision | 13:36 |
| Fl1nt | frickler, why would you stop deploying to pypi, that's exactly the opposite of what people want | 13:36 |
| mnasiadka | currently we are cycle-with-rc | 13:36 |
| frickler | +trailing? | 13:36 |
| SvenKieske | I mean we have regularly people asking about pypi packages, so from a user point of view it might be better to go in the other direction and publish more regularly. | 13:36 |
| mnasiadka | yes, +trailing | 13:37 |
| mnasiadka | but if we go untagged, then it's probably worse mayhem | 13:37 |
| SvenKieske | either way, the current state is not good, I guess everybody agrees on that. | 13:37 |
| frickler | I think people using pypi do not get what they expect | 13:37 |
| SvenKieske | can the push to pypi not be automated? I really have no clue how much work it is | 13:37 |
| mnasiadka | true | 13:37 |
| mnasiadka | well, we need to raise a patch in openstack/releases | 13:37 |
| frickler | it is automated as part of tagging a release | 13:37 |
| Fl1nt | frickler, quite the opposite, they exactly got a release semver that you know what is contained | 13:37 |
| mnasiadka | question is why do they not get what they expect | 13:38 |
| mnasiadka | because if they expect bugs fixed in a certain bugfix release that gets released every month | 13:38 |
| Fl1nt | because kolla stable releases keeps moving | 13:38 |
| mnasiadka | then I agree we would need to be better in bug squashing and versions management | 13:38 |
| frickler | yes, and there's nobody around to do that | 13:39 |
| Fl1nt | I could tell you what we're expecting at my scale, can't talk for everybody | 13:39 |
| Fl1nt | frickler, I do | 13:39 |
| SvenKieske | well we do regular bugfixes and backports, my understanding was, that these are a) not tagged(?) and b) not published to pypi | 13:39 |
| SvenKieske | I'm sure I'm missing something, currently I understand that we miss a patch in openstack/releases, is that all to do? there must be more, no? | 13:40 |
| mmalchuk | agree... as backported soo many fixes | 13:40 |
| Fl1nt | We've 187 countries, 4 continents, 5 regions per continents, 3 AZ per regions worldwide global cluster, we do not want things to evolve from build to build of a certain release, so we base on snapshot and freeze and pypi | 13:40 |
| Fl1nt | so the workflow is as is | 13:41 |
| frickler | SvenKieske: you always ask for written docs, now we have them here and you don't read them ;) https://docs.openstack.org/kolla/latest/contributor/release-management.html#stable-branch-lifecycle | 13:41 |
| mnasiadka | frickler: that's true, we don't even have people to triage bugs and prioritise them, not speaking about closing them | 13:41 |
| mmalchuk | we have them. me? Sven? | 13:42 |
| SvenKieske | frickler: well when it comes to openstack docs, I either ask, google, a dev on IRC or chatgpt, because navigating the docs site is...dangerous | 13:42 |
| mnasiadka | And I agree it's a discussion for PTG - how to manage that going forwards | 13:42 |
| Fl1nt | We build on xena-cos8-13.0.9 using pypi and local build, those build need to be reproducible 100% we can't have build A do diverge from build B, with current kolla structure, it's managable through tags, but yet we still sometimes have sleeps as some package on a tag aren't fixed, so to circumvent that we build against a specific repo snapshot for a specific release build | 13:42 |
| mnasiadka | because the current model is a bit broken | 13:42 |
| SvenKieske | agreed on PTG discussion | 13:43 |
| mnasiadka | ok, let's go to additional agenda from whiteboard, because there's ~15 minutes left | 13:44 |
| mnasiadka | #topic Additional agenda (from whiteboard) | 13:44 |
| SvenKieske | but thanks for the lifecycle link, but it seems we do not do what's documented there ;) | 13:44 |
| mnasiadka | frickler: jobboard needs love :) | 13:44 |
| frickler | yes, needs time, too. next time ;) | 13:44 |
| mnasiadka | jsuazo - TaaS (tap-as-a-service) | 13:45 |
| frickler | you can drop it from agenda for now I think | 13:45 |
| mnasiadka | I commented today https://review.opendev.org/c/openstack/kolla/+/885151 | 13:45 |
| jsuazo | mnasiadka: Thanks! Btw we have tested both changes up to Zed, so everything should be working fine. | 13:46 |
| mnasiadka | once Kolla part is sort-of-solved - we can review kolla-ansible part | 13:46 |
| jsuazo | noted | 13:46 |
| mnasiadka | jsuazo: I'm not saying everything shouldn't be working fine, my question is why are we overriding the version from upper-constraints - and should we even be doing that | 13:48 |
| jsuazo | mnasiadka: my comment wasn't related to yours, just mentioning. The version change was done because if left on the constraints, we were having dependency mismatch errors on neutron | 13:49 |
| mnasiadka | yes, because in the patch we're trying to install tap-as-a-service from the stable branch, not from pypi | 13:49 |
| mnasiadka | question if we should | 13:49 |
| mmalchuk | jsuazo bump version in requiremets? | 13:49 |
| jsuazo | Older version didn't work when tested, had to up the version to get the expected results. | 13:50 |
| frickler | do we really need this in all of neutron? can't it be optional somehow? | 13:50 |
| mnasiadka | #link https://review.opendev.org/c/openstack/kolla-ansible/+/885417 | 13:50 |
| mnasiadka | this is the kolla-ansible part | 13:50 |
| jsuazo | frickler: I believe we included a variable to opt in and out, if not we could implement it | 13:51 |
| mnasiadka | basically if we have a feature in kolla-ansible - it makes sense to install taas in the image | 13:51 |
| mnasiadka | question why taas is in upper-contraints | 13:51 |
| frickler | I'm not convinced it makes sense to include any possible feature in all neutron containers | 13:52 |
| jsuazo | mmalchuk: Would love to do so, didn't work out how to D; I'll take any pointers | 13:52 |
| opendevreview | Michal Arbet proposed openstack/kolla-ansible master: [DNM] Just test something https://review.opendev.org/c/openstack/kolla-ansible/+/893609 | 13:52 |
| Fl1nt | isn't TAPaaS supposed to be a ghost town? | 13:52 |
| frickler | seems it has been revived | 13:53 |
| mmalchuk | jsuazo https://opendev.org/openstack/requirements.git | 13:53 |
| mmalchuk | jsuazo just make change there | 13:53 |
| mmalchuk | jsuazo bump or even drop | 13:53 |
| Fl1nt | frickler, last patch is 3 months ago tho | 13:54 |
| SvenKieske | I'll need to be in another meeting at 0400 | 13:54 |
| jsuazo | Fl1nt: might be, but my company is pretty interested on these features, so we are working with one of the remaining members on how revive it | 13:54 |
| Fl1nt | jsuazo, ok, good to read that then :D | 13:54 |
| jsuazo | we are already working on bug fixes and some new features for it | 13:54 |
| mnasiadka | well, anyway - it has been added to u-c long time ago for networking-midonet | 13:55 |
| jsuazo | mmalchuk: Thanks! | 13:55 |
| mnasiadka | I don't mind installing one lonely pypi package, but overriding u-c seems like an overkill for now | 13:55 |
| mnasiadka | But maybe it's just me | 13:56 |
| mnasiadka | let's wait for an answer in the patchset | 13:56 |
| mnasiadka | #topic Open discussion | 13:56 |
| mnasiadka | (a.k.a. ranting time) | 13:56 |
| frickler | I actually think we need more u-c overriding, but that's another topic for another day | 13:56 |
| mmalchuk | Gnocchi | 13:56 |
| mmalchuk | lets build it | 13:56 |
| mmalchuk | https://review.opendev.org/q/I3ca4e10508c26b752412789502ceb917ecb4dbeb | 13:56 |
| mmalchuk | all fixed, CI passed | 13:57 |
| frickler | the version bump should merge on master first IMO | 13:57 |
| frickler | https://review.opendev.org/c/openstack/kolla/+/893722 | 13:57 |
| mmalchuk | not related | 13:57 |
| jangutter | jsuazo updating openstack/requirements/upper-constraints.txt means that non-kolla projects like devstack start testing the same thing too, rather than kolla being unique. | 13:57 |
| mnasiadka | frickler: once it passes | 13:58 |
| mmalchuk | frickler master wes build from the master | 13:58 |
| mmalchuk | was* | 13:58 |
| mmalchuk | nevermind | 13:58 |
| mmalchuk | ok | 13:58 |
| mmalchuk | lack of Kayobe review for a week again: | 13:59 |
| mmalchuk | https://review.opendev.org/c/openstack/kayobe/+/861397 | 13:59 |
| mmalchuk | https://review.opendev.org/c/openstack/kayobe/+/879554 | 13:59 |
| mmalchuk | bbezak ^ | 13:59 |
| mmalchuk | and new one https://review.opendev.org/c/openstack/kayobe/+/893688 | 14:00 |
| mnasiadka | ok | 14:00 |
| mnasiadka | time is up | 14:00 |
| mnasiadka | see you next week | 14:00 |
| mnasiadka | #endmeeting | 14:00 |
| opendevmeet | Meeting ended Wed Sep 6 14:00:18 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/kolla/2023/kolla.2023-09-06-13.01.html | 14:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/kolla/2023/kolla.2023-09-06-13.01.txt | 14:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/kolla/2023/kolla.2023-09-06-13.01.log.html | 14:00 |
| mmalchuk | I want done with https://storyboard.openstack.org/#!/story/2002009 on stable branches | 14:00 |
| mmalchuk | mnasiadka thanks | 14:00 |
| Fl1nt | ok guys, I'd like to thanks kevko SvenKieske mmalchuk for their understanding about the designate patch issue, I'll let you guys follow up as you want with this thing, if you want to restore it, I'm fine with that as there are still people/users that would probably benefit from it, but I won't work on it anymore neither do I will contribute back downstream patch from now on. Thanks a lot for all the hard work | 14:00 |
| Fl1nt | and efforts you guys made, so long and thanks for the fish. | 14:00 |
| Fl1nt | I hope you'll find a way to manage those contribution issues soon. | 14:01 |
| Fl1nt | See ya | 14:01 |
| mmalchuk | Fl1nt please restore changes | 14:01 |
| Fl1nt | mmalchuk, sure | 14:01 |
| SvenKieske | yeah, only owner can restore AFAIK, had a problem with this in keystone as well | 14:01 |
| mnasiadka | a core reviewer can restore as well | 14:02 |
| Fl1nt | ah didn't knew, I though core were able to restore | 14:02 |
| mmalchuk | nope | 14:02 |
| Fl1nt | ok, well, it's restored | 14:02 |
| mmalchuk | only one? abandoned several | 14:02 |
| Fl1nt | hope you guys will find appropriate way to manage that. | 14:03 |
| Fl1nt | mmalchuk, I've restored both patchs. | 14:03 |
| mmalchuk | cool, thanks | 14:03 |
| Fl1nt | tbn: splitting this patch in smaller chunks will create a dependency hell | 14:04 |
| mmalchuk | imho we could find time to manage them | 14:04 |
| Fl1nt | it's up to you now ;-) | 14:04 |
| Fl1nt | see ya everyone. | 14:04 |
| mmalchuk | to team) | 14:04 |
| mmalchuk | bye | 14:04 |
| mnasiadka | ok, so https://review.opendev.org/c/openstack/kolla-ansible/+/893769 (revert) should be merged ASAP? | 14:07 |
| mmalchuk | frickler https://review.opendev.org/c/openstack/kolla/+/893722 | 14:27 |
| mmalchuk | frickler CI passed | 14:27 |
| opendevreview | Michal Arbet proposed openstack/kolla-ansible master: [DNM] Just test something https://review.opendev.org/c/openstack/kolla-ansible/+/893609 | 15:06 |
| opendevreview | Verification of a change to openstack/kayobe stable/2023.1 failed: Pass through kolla inventories as is https://review.opendev.org/c/openstack/kayobe/+/884822 | 15:40 |
| frickler | mnasiadka: I think that should not merge at all, but I need to doublecheck tomorrow | 15:46 |
| mnasiadka | frickler: did w-1 | 15:47 |
| mnasiadka | waiting for you :) | 15:47 |
| frickler | thx | 15:47 |
| opendevreview | Will Szumski proposed openstack/kolla-ansible master: Support exposing prometheus_server externally https://review.opendev.org/c/openstack/kolla-ansible/+/828695 | 16:27 |
| opendevreview | Verification of a change to openstack/kolla master failed: Use latest tagged version from gnocchi again https://review.opendev.org/c/openstack/kolla/+/893722 | 16:55 |
| frickler | meh :( | 16:59 |
| opendevreview | Merged openstack/kayobe stable/2023.1: Pass through kolla inventories as is https://review.opendev.org/c/openstack/kayobe/+/884822 | 18:34 |
| *** ralonsoh is now known as ralonsoh_away | 18:55 | |
| opendevreview | Merged openstack/kolla master: Use latest tagged version from gnocchi again https://review.opendev.org/c/openstack/kolla/+/893722 | 19:56 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!