| *** ianw is now known as Guest52 | 01:07 | |
| *** Guest52 is now known as ianw | 01:29 | |
| opendevreview | Yi Yang proposed openstack/neutron master: Add a new RPC get_subnets https://review.opendev.org/c/openstack/neutron/+/797221 | 02:40 |
|---|---|---|
| opendevreview | Merged openstack/neutron stable/wallaby: Read keepalived initial state in parallel to interface monitoring https://review.opendev.org/c/openstack/neutron/+/796865 | 05:09 |
| opendevreview | liuyulong proposed openstack/neutron master: Add agent extension 'dhcp' for ovs agent https://review.opendev.org/c/openstack/neutron/+/776567 | 06:51 |
| opendevreview | liuyulong proposed openstack/neutron master: Add fullstack test case for OVS DHCP extension https://review.opendev.org/c/openstack/neutron/+/776568 | 06:51 |
| opendevreview | Kamil Sambor proposed openstack/neutron master: Enable querier for multicast (IGMP) in OVN https://review.opendev.org/c/openstack/neutron/+/796997 | 07:24 |
| ltomasbo | hi folks! sorry for the dummy/newbie question. Any reason why here https://review.opendev.org/c/openstack/neutron/+/797087/1/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py, the port context at create_port does not have the tags information? I thought that was on the post_commit action. | 07:40 |
| *** rpittau|afk is now known as rpittau | 07:41 | |
| slaweq | ltomasbo IIRC tags are separate resource and are managed by service plugin | 08:13 |
| slaweq | probably that's why they are missing in that context | 08:13 |
| slaweq | maybe we should somehow add them to that context if that can be useful | 08:14 |
| ltomasbo | slaweq, ok, but I should be able to fetch them there by using the tag service pluging? | 08:17 |
| slaweq | ltomasbo I think so because why not? | 08:17 |
| ltomasbo | great! I'll give that a try | 08:17 |
| ltomasbo | slaweq, most probably the only reason is me not knowing how to do it! I'll check a bit on the code base to see how that is done in other places! thanks! | 08:18 |
| ltomasbo | slaweq++ | 08:18 |
| slaweq | ltomasbo++ | 08:26 |
| opendevreview | Merged openstack/neutron stable/wallaby: ovn: Don't use dict.remove() for filtering dhcp ports in db-sync https://review.opendev.org/c/openstack/neutron/+/796872 | 08:49 |
| amotoki | ltomasbo: a tag is not intended to use by mechanism driver by design. it is just for API consumer usage. | 08:59 |
| amotoki | ltomasbo: if your driver depends on some information from "tags", it is not a good direction. | 09:00 |
| amotoki | so I believe the current situation is corect that port context does not contain tag information. | 09:02 |
| ltomasbo | amotoki, right, my intention here was to use it as kind of a simple/first-iteration API, so the user will add that information into the port, and I just needed the information to be there so that it is present on OVN SB DB (external_ids) and then a different agent will consume that information from the OVN SB DB, so, it is kind of external usage | 09:04 |
| ltomasbo | dalvarez, ^ | 09:04 |
| ltomasbo | cgoncalves, ^ | 09:04 |
| amotoki | ltomasbo: do you mean a backend (i.e. OVN in this case) would like to get some information from "tag"? | 09:05 |
| ltomasbo | amotoki, more than the ml2/ovn backend, an agent running on the compute nodes | 09:07 |
| ltomasbo | it just read information from the OVN SB DB, and do some configurations on the node based on them | 09:08 |
| amotoki | ltomasbo: so perhaps it is not the right usage of tags. tags are under API users and they can clear all tags. | 09:08 |
| ltomasbo | yes yes, the idea is that user (tenant) is adding/removing the tags | 09:09 |
| ltomasbo | amotoki, and depending on a given tag being present or not, the agent will need to do something | 09:09 |
| ltomasbo | so, intention is to be based on the tag information added by the user, meaning using the tags as the user API for triggering some actions | 09:10 |
| amotoki | ltomasbo: and any implementations should not assume a specific tag. | 09:10 |
| amotoki | so it sounds the implementation depends on tags.... | 09:11 |
| ltomasbo | amotoki, I understand this is on the "edge", but why not? if it is external agent, just reading the tags from OVN DBs and using the tags as the API, for example, if this tag is present "expose-ip:true", then the agent sees the tag on the OVN DB (external_ids), and do some action (related to the host configuration) | 09:13 |
| opendevreview | Manu B proposed openstack/neutron-specs master: BGPaaS enhancements https://review.opendev.org/c/openstack/neutron-specs/+/783791 | 09:14 |
| slaweq | lajoskatona obondarev hi, can You guys take another look at https://review.opendev.org/c/openstack/neutron/+/686343 ? | 09:15 |
| slaweq | thx in advance | 09:15 |
| slaweq | and also https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/789709 as it should be now ready to go | 09:16 |
| amotoki | ltomasbo: if it is completely out side of neutron, it is okay. All API users can do anything. | 09:17 |
| amotoki | ltomasbo: I am not sure I understand your needs. In the initial design, "tags" is completely a feature in the neutron API side and the concensus when implemented is we should not pass tags information to an implementation like driver, so it is not included in port_context. | 09:17 |
| amotoki | ltomasbo: what is the real need you would like to achieve? | 09:18 |
| ltomasbo | amotoki, right! so that was to protect from abusing it... and it seems that is kind of what I want to do here :) | 09:18 |
| opendevreview | Merged openstack/neutron stable/victoria: ovn: Don't use dict.remove() for filtering dhcp ports in db-sync https://review.opendev.org/c/openstack/neutron/+/797013 | 09:19 |
| opendevreview | Merged openstack/neutron master: Fix QoS dscp rule permissions in documentation https://review.opendev.org/c/openstack/neutron/+/796457 | 09:19 |
| lajoskatona | slaweq: checking | 09:21 |
| ltomasbo | amotoki, so I wanted to have a quick API where the user can define if he want their VMs exposed through BGP by just adding a tag basically saying: I want this VM exposed. Then I wanted to deploy an agent (no neutron) in the openstack nodes that watches information from OVN SB DB (in this case the port_binding table) and does the needed actions (BGP reconfiguration) for the ports where the user stated they wanted to | 09:21 |
| ltomasbo | expose it | 09:21 |
| lajoskatona | ltomasbo: why You can't use current API for BGP? | 09:24 |
| ltomasbo | lajoskatona, you mean Neutron Dynamic Routing one? | 09:24 |
| lajoskatona | ltomasbo: yes | 09:25 |
| ltomasbo | lajoskatona, does it have an API to decide what VMs to expose? I thought it was exposing all the VMs in a network (if created from the address-scope/subnet-pool) | 09:26 |
| lajoskatona | ltomasbo: yeah currently only networks can be added | 09:28 |
| lajoskatona | ltomasbo: there's a spec to add more possibility: https://review.opendev.org/c/openstack/neutron-specs/+/783791 | 09:28 |
| ltomasbo | lajoskatona, case here was to expose VMs on the provider networks, or with FIPs, instead of VMs on a tenant network, that is why I was looking for a quick API | 09:29 |
| ltomasbo | lajoskatona, nice! thanks! | 09:29 |
| ltomasbo | lajoskatona, that is only for ml2/ovs though, right? (just saw the qrouter namespace there) | 09:29 |
| lajoskatona | ltomasbo: perhaps it looks more work but on the long term seems better to add an option to existing API | 09:30 |
| lajoskatona | ltomasbo: yes it supposed to work with os-ken, as I know the current plans | 09:30 |
| ltomasbo | lajoskatona, indeed! | 09:31 |
| amotoki | ltomasbo: the basic idea of "tags" is "tags" is just information by users and "tags" does not affect any behavior. What I concern is that you seem to use "tags" API as an easy way to pass some information to the system. | 09:32 |
| amotoki | ltomasbo: if you woul dlike to control whether a VM is advertised via BGP, perhaps it is better to add some small feature/flag to the existing API. | 09:33 |
| ltomasbo | amotoki, got it! and yeah, I think you are right about it. And in fact the tags was more of a "workaround" until a real API (probably on NDR) is implemented | 09:36 |
| amotoki | ltomasbo: thanks. anyway what you mention sounds a reasonable use case to me too :) | 09:37 |
| ltomasbo | amotoki, and I understand you don't want to extend the conext, so maybe we need to look for a different temporal solution here | 09:38 |
| ltomasbo | amotoki, one thing though... I notice the maintenance task is actually later on adding that information, so eventually the tags are propagated (if using my patch) | 09:38 |
| ltomasbo | not sure if that was intended, or a mistake/bug and the context information should not be there either | 09:39 |
| amotoki | ltomasbo: the fact that port_context does not contain "tags" information is intentional when "tags" API was implemented. If we change it, it is a kind of RFE. | 09:41 |
| ltomasbo | amotoki, yes, I meant the fact that ovn maintenance task seems to have that information into the port_context | 09:42 |
| amotoki | ltomasbo: at lesat it is a big change in the meaning of the current "tags" concept because the system will define some revered word in "tags". It sounds we need an API to control expose-ip=true/false | 09:46 |
| cgoncalves | so that would be a neutron api extension? | 09:48 |
| ltomasbo | amotoki, right, I was not thinking of reserving words... but yeah, good point | 09:48 |
| ltomasbo | amotoki, thanks for all the inputs! really appreciated! amotoki++ | 09:49 |
| amotoki | ltomasbo: you're welcome. | 09:49 |
| amotoki | perhaps I should add some note on this to the tag section in the neutron API reference. | 09:50 |
| ltomasbo | amotoki, reading this https://docs.openstack.org/neutron/latest/contributor/internals/tag.html, and I think it is already clear: "Tagging resources can be used by external systems or any other clients of the Neutron REST API (and NOT backend drivers)." It was me not seeing that before! xD | 09:51 |
| ltomasbo | amotoki, that said... point 5 there could be somehow similar to what we want tags for | 09:52 |
| ltomasbo | "new features like get-me-a-network or a similar port scheduler could choose a network for a port based on tags" | 09:52 |
| amotoki | ltomasbo: yeah, it is documented there. point 5 is a bit cofusing. get-me-a-network is a kind of an orchestration which calls neutron API internally. | 09:56 |
| amotoki | ltomasbo: so, get-me-a-network feature can be considered as a kind of API clients. for example, we can add some tags created by "get-me-a-network" to a network created by the feature. API user can delete the newtork directly. it does not control the system behavior. that's an example. | 09:58 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Remove FIP agent's gw port when L3 agent is deleted https://review.opendev.org/c/openstack/neutron/+/787691 | 09:59 |
| opendevreview | liuyulong proposed openstack/neutron master: Revert "Add CONTEXT_READER decorator to "get_ha_router_port_bindings"" https://review.opendev.org/c/openstack/neutron/+/797266 | 10:07 |
| opendevreview | Yi Yang proposed openstack/neutron-specs master: Add spec for Openflow-based DVR L3 implementation https://review.opendev.org/c/openstack/neutron-specs/+/796746 | 10:08 |
| opendevreview | Yi Yang proposed openstack/neutron-specs master: Add spec for Openflow-based DVR L3 implementation https://review.opendev.org/c/openstack/neutron-specs/+/797252 | 10:09 |
| ltomasbo | amotoki, right! got it | 10:11 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron stable/ussuri: [DNM] [stable/ussuri] Set USE_PYTHON3 for neutron-tempest-slow-py3 job https://review.opendev.org/c/openstack/neutron/+/797273 | 10:12 |
| bcafarel | slaweq: ^ test fix for recent ussuri breakage https://bugs.launchpad.net/neutron/+bug/1933086 (though proper fix may be in tempest, not sure why this broke few days ago) | 10:13 |
| opendevreview | Yi Yang proposed openstack/neutron-specs master: Add spec for Openflow-based DVR L3 implementation https://review.opendev.org/c/openstack/neutron-specs/+/796746 | 10:17 |
| slaweq | bcafarel thx, I will check it after I will finish investigation of the functional breakage :) | 10:29 |
| opendevreview | liuyulong proposed openstack/neutron master: Add agent extension 'dhcp' for ovs agent https://review.opendev.org/c/openstack/neutron/+/776567 | 10:30 |
| opendevreview | liuyulong proposed openstack/neutron master: Add fullstack test case for OVS DHCP extension https://review.opendev.org/c/openstack/neutron/+/776568 | 10:30 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron-tempest-plugin master: Add test for mac learning https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/796267 | 10:42 |
| opendevreview | Lajos Katona proposed openstack/networking-bgpvpn stable/train: stable only: Fix failing jobs and make l-c non-voting https://review.opendev.org/c/openstack/networking-bgpvpn/+/796808 | 10:46 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Add CONTEXT_WRITER decorator to delete_floatingip_agent_gateway_port https://review.opendev.org/c/openstack/neutron/+/797280 | 10:51 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-lib master: Add Neutron's functional job to the neutron-lib's CI https://review.opendev.org/c/openstack/neutron-lib/+/797281 | 10:54 |
| *** elvira is now known as elvira-lunch | 11:16 | |
| opendevreview | Lajos Katona proposed openstack/networking-bgpvpn stable/train: stable only: Fix failing jobs and make l-c non-voting https://review.opendev.org/c/openstack/networking-bgpvpn/+/796808 | 12:16 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/train: Make default hypervisor hostname compatible with libvirt https://review.opendev.org/c/openstack/neutron/+/796837 | 12:21 |
| *** elvira-lunch is now known as elvira | 12:24 | |
| opendevreview | Gaudenz Steinlin proposed openstack/neutron master: Copy existing IPv6 leases to generated lease file https://review.opendev.org/c/openstack/neutron/+/762874 | 12:57 |
| admin1 | what is shared between nova and neutron db such that i can get the instance-id from floating-ip ? | 13:30 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron stable/ussuri: [stable/ussuri] Set USE_PYTHON3 for neutron-tempest-slow-py3 job https://review.opendev.org/c/openstack/neutron/+/797273 | 13:30 |
| opendevreview | Lajos Katona proposed openstack/networking-bgpvpn stable/train: stable only: Fix failing jobs and make l-c non-voting https://review.opendev.org/c/openstack/networking-bgpvpn/+/796808 | 13:41 |
| opendevreview | Kamil Sambor proposed openstack/neutron master: Enable querier for multicast (IGMP) in OVN https://review.opendev.org/c/openstack/neutron/+/796997 | 13:52 |
| velizarx_ | Hey ralonsoh. I want to raise my question about RBAC bgpvpn implementation again. As I see we cannot initialize RBAC Object class for bgpvpn inside networking-bgpvpn repository because of this dinamic load (https://github.com/openstack/neutron/blob/1ad9ca56b07ffdc9f7e0bc6a62af61961b9128eb/neutron/db/rbac_db_models.py#L85). I've already tried to do this and it did not work. So my question, can I add RBACObject and RBAC database model to the | 13:54 |
| velizarx_ | main neutron repo? | 13:54 |
| velizarx_ | question related to this RFE https://bugs.launchpad.net/neutron/+bug/1931100 | 13:55 |
| slaweq | velizarx_ ralonsoh is not available today, please ping him tomorrow :) | 13:56 |
| velizarx_ | slaweq maybe you can answer my question? | 13:57 |
| slaweq | velizarx_ I will take a look but later, now I'm in the meeting | 13:58 |
| slaweq | sorry | 13:58 |
| velizarx_ | np, thank you | 13:58 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Use ovs constants from neutron-lib https://review.opendev.org/c/openstack/neutron/+/797120 | 14:01 |
| *** gthiemon1e is now known as gthiemonge | 14:04 | |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Remove ovs agent's common constants module https://review.opendev.org/c/openstack/neutron/+/797121 | 14:06 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/train: Read keepalived initial state in parallel to interface monitoring https://review.opendev.org/c/openstack/neutron/+/796999 | 14:37 |
| haleyb | slaweq: is there someone looking at the neutron-functional-with-uwsgi failure rate? it seems red on a lot of recent patches with a similar 'mismatch' failure | 14:51 |
| slaweq | haleyb fix for that issue is in the gate already https://review.opendev.org/c/openstack/neutron/+/797280 | 14:53 |
| haleyb | slaweq: thanks, that is it :) | 14:54 |
| opendevreview | Slawek Kaplonski proposed openstack/networking-ovn stable/train: [EM releases] Move non-voting jobs to the experimental queue https://review.opendev.org/c/openstack/networking-ovn/+/796474 | 14:59 |
| opendevreview | Sebastian Lohff proposed openstack/neutron master: Correctly label port as SubPort in SubPortNotFound https://review.opendev.org/c/openstack/neutron/+/788706 | 15:01 |
| admin1 | hi all .. when i do openstack floating ip show $ip, i get port_details | admin_state_up='True', device_id='641e5eb7-32bf-48d4-81d9-e96177c10f60', device_owner='compute:nova' ... where does this data come from ? i mean from which table ? | 15:04 |
| slaweq | admin1 - https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.py#L103 - here is Port | 15:06 |
| slaweq | Port's table model | 15:07 |
| slaweq | You should find it there | 15:07 |
| opendevreview | Slawek Kaplonski proposed openstack/networking-ovn stable/train: [EM releases] Move non-voting jobs to the experimental queue https://review.opendev.org/c/openstack/networking-ovn/+/796474 | 15:18 |
| opendevreview | Flavio Fernandes proposed openstack/networking-ovn stable/train: Ensure that load balancer is added to logical switch https://review.opendev.org/c/openstack/networking-ovn/+/796169 | 15:28 |
| jrosser | does anyone know what determines the source IP address for the neutron bgp agent when connecting to a bgp peer? | 15:30 |
| *** gthiemon1e is now known as gthiemonge | 15:51 | |
| *** rpittau is now known as rpittau|afk | 16:00 | |
| opendevreview | Lajos Katona proposed openstack/networking-bgpvpn stable/train: stable only: Fix failing jobs and make l-c non-voting https://review.opendev.org/c/openstack/networking-bgpvpn/+/796808 | 16:19 |
| mlavalle | slaweq: I tried to follow the priority reviews ling here: https://docs.openstack.org/neutron/latest/contributor/dashboards/index.html#gerrit-dashboards. I'm getting a 400 error. Do we still use this link? Any quick idea as to why it might be failing? No rush, I'm just trying to review some code :-) | 16:41 |
| admin1 | slaweq, one more question .. which table holds the IPs of the router itself ? | 17:04 |
| admin1 | not floating ips | 17:04 |
| frickler | mlavalle: some dashboard started failing after the gerrit upgrade some time ago. seems only the first link is broken, I can try to take a closer look tomorrow | 17:06 |
| frickler | jrosser: the local address of the host the n-d-r agent runs on | 17:07 |
| jrosser | frickler: well that’s what makes it interesting, I don’t have/otherwise need an ip on my l3 agent host in the public subnet | 17:10 |
| mlavalle | frickler: :-) No rush on my part. I just wanted to give visibility to what I found | 17:12 |
| mlavalle | Thanks! | 17:12 |
| frickler | jrosser: it doesn't have to be public, we use a dedicated private net for this. the nexthops announced with the prefixes are completely independent of this | 17:15 |
| opendevreview | Merged openstack/neutron stable/victoria: Read keepalived initial state in parallel to interface monitoring https://review.opendev.org/c/openstack/neutron/+/796866 | 17:50 |
| opendevreview | Merged openstack/neutron master: [Docs] Add info about vlan transparent networks' MTU https://review.opendev.org/c/openstack/neutron/+/796637 | 17:51 |
| opendevreview | Merged openstack/python-neutronclient master: Changed minversion in tox to 3.18.0 https://review.opendev.org/c/openstack/python-neutronclient/+/794405 | 18:51 |
| opendevreview | Brian Haley proposed openstack/networking-ovn stable/train: Add Health Monitor support https://review.opendev.org/c/openstack/networking-ovn/+/796063 | 19:01 |
| opendevreview | Merged openstack/neutron-tempest-plugin master: Remove allowed_address_pair API tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/796462 | 19:29 |
| opendevreview | Merged openstack/networking-odl stable/stein: [EM releases] Move non-voting jobs to the experimental queue https://review.opendev.org/c/openstack/networking-odl/+/796496 | 22:11 |
| opendevreview | Merged openstack/networking-odl stable/train: [EM releases] Move non-voting jobs to the experimental queue https://review.opendev.org/c/openstack/networking-odl/+/796475 | 22:16 |
| opendevreview | Merged openstack/networking-bagpipe stable/stein: [EM releases] Move non-voting jobs to the experimental queue https://review.opendev.org/c/openstack/networking-bagpipe/+/796497 | 23:30 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!