On Wed, Feb 19, 2025, at 2:53 PM, Brian Haley wrote:
On 2/18/25 3:59 PM, Ihar Hrachyshka wrote:
On Tue, Feb 18, 2025 at 1:14 PM Brian Haley <haleyb.dev@gmail.com <mailto:haleyb.dev@gmail.com>> wrote:
Hi Jani,
On 2/18/25 5:47 AM, Jani Heikkinen wrote: > We have been installing openstack Dalmatian based on Debian packages on > our institution. > > I am currently trying to configure OVN neutron metadata service, but it > seems very hard to find how OVN actually currently does it. > > See [1.]. The documentation states first, that ovn-metadata-agent will > run with a netns and haproxy instance on hypervisor. > > But there is also a reference to having metadata support in > ovn-controller. In addition, I have seen hints suggesting that > neutron-ovn-agent and neutron-ovn-metadata-agent would be exclusive to > each other.
The doc you linked is from the old networking-ovn repository, and was more intended for developers, not cloud admins. All code is now in the neutron repository (including this old design document) since we didn't want to throw it all out. Metadata is not supported in ovn-controller.
Perhaps the doc should not be published if it's old and confusing.
I actually don't know how to have it not show up on docs.openstack.org and codesearch didn't find an obvious answer. I'll gladly make a change if someone can point me in the right direction.
-Brian
If the documentation is still valid for some users you probably don't want to remove it entirely. I'm not sure if the old docs apply to old versions of neutron and openstack. I think this exposes a gap in the project retirement process where we don't update the documentation for a project before retiring it. In this case networking-ovn was retired but the documentation doesn't appear to warn anyone about that. Ideally we would've updated the docs in networking-ovn to indicate the retired state, let those publish, then retire the project itself. Considering that didn't happen I think we have some options: We could decide that the docs aren't valuable to anyone anymore and an OpenDev admin can delete them from afs manually. We could unretire the project, update its docuementation, then retire it again. Someone could supply updated documentation edits that an OpenDev admin could manually apply. There are probably other options that I haven't considered too.