 Hi everyone, I'm Savek and I'm a Neutron Ptl since few cycles. I started serving as Ptl for Neutron in Uzuri and I continued that through Victoria and now in Wallaby. I work for Red Hat and you can catch me on IRC mostly on OpenStack Neutron channel at pre-note if you need anything related to Neutron. Today I wanted to show you some updates about what Neutron team achieved in the Victoria cycle. So let's start with some general statistics based on Stalkalytics first. So Neutron team matched almost 600 patches to the Neutron and Neutron stadium projects during Victoria cycle. We completed 5 blueprints, we closed almost 170 bags and there was more than 100 individual contributors who sent at least one patch to the Neutron project in this last cycle. As you can see the project seems to be pretty healthy and stable, we have a bunch of contributors, we are doing a lot of work every release. And now let's talk a bit about new features which we introduced in Victoria. So first of all we added support for metadata over IPv6. Neutron is the first project as far as I know which provides metadata service over IPv6 address. We are using link local IPv6 address for that. It is equivalent of the IPv4 address which every one of you probably knows, 169.254.169.254. Now you can get metadata from metadata service in IPv6 online networks using this new link local IP address. As it is link local IP address you have to specify give interface name in the URL when doing request. But other than that everything else should work in exactly the same way like in IPv4 world and you should be able to get metadata from metadata service. One thing which you should be aware of is that CloudInnit for example as far as I know don't support metadata over IPv6 yet. So CloudInnit will not work with IPv6 only networks for now but if you have some own scripts or if you want to add some your own, I think it's called data provider in CloudInnit. You can do that and you can use IPv6 to get metadata. Next thing which we introduced in this release is support for flat networks in the DVR distributed routers. Previously you could only attach to the DVR routers VLAN or panel-based networks like Wakeslan or GRE networks. If you attached flat network to the DVR routers different strange things could happen like for example duplicate packets sent through the interfaces on this network and things like that. Some more info about that is available in the related bug report which is linked on this slide. Another feature which I want to highlight here are some OVN related things. Basically in UZU Recycle we merged OVN backend and OVN driver to the Neutron core repository. So OVN became one of the entry driver, Neutron driver instead of being a separate stadium project. But we know that OVN has got some feature parity gaps between comparing to ML2 OVS and we are working hard to close those gaps every cycle. And in Victoria we added support for floating IP port forwarding and for router availability zones in the OVN driver. So basically you can use port forwarding with OVN backend now. And the VM driver will also now read availability zone hints from your router and will schedule router ports accordingly to the given availability zones. We also added a couple of new config options which may be pretty important to know from operator's point of view. First of such options is KIPA-LIFE-D use no contract. This one is important if you are using KIPA-LIFE-D older than 2.0 because in such version KIPA-LIFE-D don't know about no track option in config file and will complain if Neutron will add such option to the KIPA-LIFE-D config file. Default value of this option is true because in the newest distribution like Ubuntu 20.04 or Fentus 8 there is already KIPA-LIFE-D 2.0 and that should work fine. But if you are using some older distro or you have your own older KIPA-LIFE-D then it may be worth to, it may be required to change this value to false. Another new config option is HTTP retries which is Neutron server config option and it basically says that how many times Neutron, Nova or ironic client used by Neutron, how many times it should retry API requests which are sent from Neutron to Nova for example with notification that port is provisioned or things like that. By default we are retrying three times in case of some network outage or some other issue, networking issue during the first request sent to Nova. But you can of course change this to some other value. Other smaller improvements which we added in the Victoria cycle are for example that all Neutron agent processes now has got the same format of the process name like Neutron server workers. So it will be visible as Neutron agent name like Neutron DHCP agent or Neutron L3 agent. And there in parenthesis there will be full original process name including interpreter user build Python and the rest of the process name which you already know. This usually is not really very important for users but if you have any custom scripts or tools which for example rely on output from PS command then you may need to update your tools accordingly to this change. From other things I can also mention that port DNS assignment now reflects DNS domain defined in the network or send by user in the API. So the API previously it was always only based on the DNS domain value specified in the Neutron config file. Now it can be specified by API. And last but not least we also changed terminology used in our code base. For example we changed words like master slice to primary and backup. This is mostly internal change in Neutron code not really very visible for users but still I think it's important to mention that we did change like that in last cycle. And that's all updates about Neutron project in Victoria cycle. Thank you and goodbye.