 So hello, I'm Matt Kosoora. I work at Rackspace. I do documentation for the most part, but I do stuff for Rackspace Private Cloud and also for upstream, particularly around Neutron, that thing that nobody seems to want to document. So kind of a lot of us got together, I guess, over the last, over a year now, and said, Neutron needs docs. Who's going to do it? Devs say, not us, and docs people don't really know how Neutron works, so it gets kind of frustrating. They keep throwing things over the fence and nothing gets done. So we kind of came together and said, why don't we take on a new style of documentation? So we came up with collaborative documentation. There's probably better words, but this will work. The ringleader is Nick Chase. He has been cracking the whip for a while now on a number of things we've been working on. Trying to keep us in line. There was a presentation in here a couple of hours ago talking about how to do global collaboration and having the person that states the agenda and basically tells people what they're doing. This guy. I'm the chief cat herder. Yeah, pretty much. The whip cracker. And, Edgar, you want to talk about yourself for a second? Yes, my name is Edgar McAnna. I work for Word Day. I'm the chief architect of the operations of the cloud. Started working in OpenStacks since 2011 and I've been a core for Neutron project. And also I like to get involved with other staff, so I've been trying to help on the documentation. And this is where I end up here. So hi, I'm Sean, and I work on documentation now quite a bit. And he works for Mirantis. I work for Mirantis. Also going back to the collaboration thing before, we are from different companies that have competing products and still get along. Yes, and then I also do Neutron work. My name is Matt Dorn. I'm a technical trainer with Rackspace. I was given the challenge of having to help develop a Neutron course, a live four-day course, and so have experience with that. And happy to be here. So basically what I would like to do here is not necessarily describe how Neutron works, but describe how we sort of put the documentation together to make it appear like it works. And some of you are chuckling at this, so I blame my boss for selecting this one. We had a little contest of which meme is going to win. So what is this? It's an experimental method to create fresh, usable, accurate, and consistent documentation through collaboration of people with different skills. So we need docs people because they write docs and they're good at it. We need devs because they wrote the stuff. We need people that are sort of in between, which is Edgar sort of a liaison, somebody to kind of tell us what we're doing and, you know, people that are in the mix. So Sean worked at some previous places. I helped. Yeah. You know, knowing how this stuff works in production is really important, because what we want to do is put together documentation that people can actually use in a real-world scenario, so it doesn't run just in DevStack. And then also how to present this information in a way that people understand. So rather than just shoving a config at people and saying go, we want to explain how it works, why it works, what doesn't work. And this is where training comes in handy because these guys go in front of people all the time and have to cram a lot of information into people's minds in a very short amount of time. And it's not just training either. It's also about this is where being a writer comes in handy because there's an organization that's involved that Devs don't necessarily think about. You know, I've written a bunch of books. It's a totally different skill. So you have to have writers involved in it to make it just understandable. Yeah. And so these are how we divided the contributor types up. Developers, subject matter experts, writers, trainers, project liaisons, and project managers. And oddly enough, a lot of us actually fall into multiple groups, which is good because we can fill in cases where people are gone for a while or they get busy at work or something like that. So the idea here is maximize existing skills. Take people that know something and somehow make it useful towards the documentation. So developers write code, not docs. If you have any Devs in here, you can all agree with that. SMEs understand and use the product. So people that have been in ops is kind of what we're looking for. People that have run Neutron in production and said, this works, this doesn't work, or understands DVR, for example. How do we actually document this? Writers create attractive, consistent docs, something that's presentable, something that like a C-level person would use to maybe determine if they want to use OpenStack in their organization. Trainers structure the information so we can maximize knowledge transfer. Project liaisons link people together. Edgar's been very helpful trying to get me in touch with people in Neutron that wrote various things like DVR and say, how does this work? And then project managers glue everything together. One of the other things we did with this, too, that was interesting is support alternative sources. So a lot of you that may have tried to contribute to OpenStack docs before had to realize we used DocBook and we used Garrett with review system and people are picky. There's lots of conventions that you maybe don't know that contribute very often and really need to basically get away from that. We want people to feel that they're free to contribute stuff. So if you're an operator and you happen to have documentation for what you deployed, just send it to us. Email it to us, make a presentation, something you've presented on before. Use your public repo. If you've got this stuff documented in GitHub or something like that. And we'll go convert it for you into the format that we like and make everything nice and consistent. I think that was a really kind of big difference between this project and a lot of the other projects because everybody kind of looked at us like that we were insane when we said... We are insane. They don't just look insane. Well, there's that. But everybody always complains, oh, I don't want to write documentation because DocBook is so hard. Yeah, OK, yeah, DocBook is hard. Get over it. Sorry. But that's what we did. We said, OK, you don't want to write DocBook? Don't write DocBook. OK, now you have no more excuses. Send us documentation. And we felt that that was really important to get other people to contribute and not just, you know, the three and a half people who are also developers and want to write at the same time. Yeah. And then looking at technical contributors can focus on technical aspects, not documentation, structure, all those things, which is kind of what we were talking about. Reusable contents, another one. Some of you work for vendors. They've already written some of these docs. No reason for you to go retype them all. Just send them in and we'll do something with it. So why a networking guide? Well, it's because nobody understands networking. We decided this was probably the most popular thing people were clamoring for for a very long time. And looking at existing documentation issues, I think some of you are like that guy, actually his dishwasher lady from the oatmeal. Oh, that guy. You're crazy too. And you know it's scattered among various documents. There was like admin guide stuff, user guide stuff. Maybe it's stuff that's old. Nobody really knows. There's a configuration reference that tells you all the config options that go into it. But how do you know they actually work? What knows do you put all these on? So we really needed to find something really concise. So I think I remember when I approached Nick like almost a year ago there was an event in Santa Clara. And actually my prey to him was like, man, we need to do something about networking. Nobody understands. Everybody just tried to read the documents, putting things together and end up with a number of different use cases. So that was the best approach that we could do is just to focus on use cases. Just give them by example what they can run with neutron and make them understand that actually if you follow the step-by-step things, you can actually make things to happen, to work. And after that they can actually start using their creativity to make whatever kind of neutron configuration they want to do and provide feedback back. But without a basis it was very hard. And I think that's really kind of an important thing about this is a lot of times you have projects that sort of solutions in search of a problem. And this was really not that. Because I remember when you came up to me at OpenStack SV and you were like, look, we have a problem. It was a very specific problem. It's like, yeah, there's documentation, but it's not useful for what we need. There's specific use cases that we need to cover and how are we going to get that done? And so that was kind of what I liked about this is this was a very specific problem that we were trying to solve. Yeah, so how do we plan this? Nick, I think you should probably take this one over because you were involved mostly with this. Yeah, so really that's kind of where we started out as I was like, okay. So now we want to do a networking guide. Well, how do we do that? All right, well, the first thing was, well, who can we Shanghai and steal and force them to work? No. It's like, who do we know that volunteers for too many things so we can get them in? And then we say, all right. So once we kind of had that initial group, we said, all right. Looking at the content like any project, the first thing is who's your audience? And we looked and we said, all right. These are people who are trying to implement Neutron. These are not newbies. They've already kind of tried a little bit. Maybe they've already run DevStack. Now they're really ready to kind of do something for real. And then, well, what do they want to do? Because if you're not covering that base, if you're not giving the audience what it is they actually want, we're back to where we were before. Yeah, well, I go back and put more documentation together that nobody can use. Exactly. And so then we kind of spent a long time, probably a little too long, going with, all right, well, what do we need to cover? What are the different scenarios? And that's what we wound up with was various scenarios of I'm trying to do this, or no, I'm trying to do that. No, I'm trying to do the other thing. And then it was a question of, all right, we don't want to reinvent the wheel. Can we grab this content from somewhere else? And from there it really became a project management thing. When do we need this? And how do we prioritize it? It's still you. It's still me. Okay. I'm delegating the stuff right now. What's wrong with this picture? See, I know. See, you should have let me run it. I have to change just a little bit. It's part of the rules. Yeah, so basically, so what we did was we said, all right, we said we have got to, what we've got to do is we have to engage the community because that's the most important part of this. We knew that a couple of documentation writers were not going to be able to do this. Specifically, I knew I wasn't going to be able to do this because I, well, I was going to say, I know nothing about networking, which is, realistically, it's not true. Now you learn. What's that? Now you learn a lot. Now I learned a lot. Yeah, I was going to say, I still feel like I know nothing about it, but then, you know, I think we've all got some pretty good imposter syndrome going on in here, but I certainly wasn't going to be able to write about it. So the question is, all right, you know, how do we get the community behind us? And because, and part of that was getting, you know, getting that liaison, getting, you know, we had Edgar already, thankfully, because I drafted him because it was his idea. I believe the word's called voluntolding in a lot of cases. Yeah, there was a lot of voluntolding. Definitely. And failing in how not to be seen. Yes. To use a rackspace, isn't what we have going around pretty often? Yes. Yes. So we drafted a lot of people, you know, I drafted Sean because he had some very special skills, and that was, I have some very special skills. And... That was after I got hired, right? This was like just around that time. Yeah, so it's a matter of kind of knowing who has those skills and also who to ask who has those skills. So you really have to use those kind of community tendrils and, you know, work your way through and who knows who and, you know, try and find those resources and put out the word. That's also very important. So this is kind of a better idea of how the contributors sort of map out. And there are some people that are not in here. Swami actually talked at the DVR thing last session and if you were in there, I collaborated with him to figure out how DVR worked. That was an interesting couple of months. But you can see some of us fit into different sections here. Some people fit multiple places. And that was kind of a pretty useful thing to kind of give an idea that you don't have to be in one particular area. So if you work start in one place, you can excel somewhere else and contribute in other ways. There was only one project manager, though, because there's only one guy crazy enough. That's one adjective. So how did we stumble? Well, networking is hard. I think everybody has come to that conclusion. A few people understand it and they tend to be busy. So it's not always easy to find them in a timely fashion. And networking as hard as overloaded, it also implies to people networking. The right people is also pretty difficult. And they're busy and they're trying to figure out how networking works, too. Meeting issues. Nick, you could probably touch a little bit to these. Yeah, so... Okay, so I'm going to come out and say this for those of you who don't know it. We didn't meet in IRC. And sorry, we're not sorry. You know, we had a very small group. We met in a not open source video service that I will not name that I'm sure you can all figure out what it was. And it wasn't because we didn't want to use an open source project. We would have used one if we could have found one. But for us, it was very much a matter of... These meetings were like face-to-face meetings for us. This was how we got... We sort of simulated the experience of all of us working together in one place. So every Friday, we would get together and we have this video meeting. And it was important for that sort of camaraderie feeling. Of course, the problem is IRC makes it really easy to record the minutes. You've got the meat bot. You can't do that in that environment. So somebody has to very specifically take down the minutes so that you can record them and report them. Just because you're not meeting an IRC doesn't mean it's not a community meeting. Yeah, it's a community meeting. You're talking to each other, but you still have to report to everyone so that the people who weren't there know what happened because we're still developing this out in the open. Time zones, we had a few issues getting everyone together, especially around daylight savings time. By the way, networking is hard. Time is also hard. Yes. So we did have a couple of things that we did learn. One is collaboration is hard. Ramping up was a big deal. This was kind of supposed to be done by Juno, and it is now Kilo. It's just because a lot of us have... There's not as many people as you think are going to get involved or they're not going to get involved as quickly or things are going to move slow for whatever reason. There's problems. It's not the greatest thing, but it's a lot better than everything else we've seen in terms of developing documentation for a particularly complicated part of OpenStack. Nick, you want to talk about your project management problems? Yeah, so just because you have a collaborative... You mean commiserate? You're wrong word there. Collaborate, commiserate, they're very close. Commiserate, yeah, that works too. But just because you have this kind of project where you're getting a lot of people from lots of different areas doesn't mean that the traditional project management risks do not apply. For example, we had some issues. We had a contractor who was working on the project at first that... Let us just say that did not work out. Two of them. And then we got another one who unfortunately became very ill and so it's just things that you expect to work out don't always work out. And just because this is a collaborative process doesn't mean that the traditional project management issues don't apply. Although I have to say this, when you come right down to it, we were all working on this in our free time, so to speak. And when you think about it, we met once a week for an hour. So overall, I think we did a pretty good job in getting this done in a reasonable period of time. Yeah, and the main thing that we wanted to get done for Kilo once we kind of boiled this down was the scenarios are most important. People want to know the most common ways to configure Neutron, how to do it, why it works, why it doesn't work, how traffic flows, diagrams specifically. Don't say anything, Ian. I see you over there. There's a lot of jokes going around about diagrams. Long story short, there's 64 of them in the networking guide so far, and we're not actually done yet, so a whole lot of stuff in there. But not just configuration is the key. We don't want to say, okay, here's a bunch of options you can use, go figure out how to deploy them. We want to say, here's a reference architecture. If you put this together and do these things, you can add Neutron with this config, and it'll work like we're talking about, and you can test it that way, and then work on deploying it in your own environment, so expand upon it. And actually, let me just kind of interject here for a minute. You've kind of touched on what we didn't say in the beginning, which is one of the points of the networking guide is to provide context for all of this. So, you know, it's easy to say, you know, set this, set this, set this, but if you don't understand why you're doing all that, if you don't understand how Neutron actually works, from a real perspective, not from a, this is what it says on the wiki perspective, then, you know, even if by some miracle you managed to get it working, you're not going to understand how to adapt that to your own situation. So that was a very big part of what we were trying to accomplish. Yeah, and a lot of the new features too with Neutron, like DVR and L3HA, simply had zero documentation, or they were like, oh, here's the one thing you can add to your DevStack config to deploy it, and it's like, well, DevStack's one node. You need multiple nodes for DVR, so this doesn't work. In fact, Juno was sort of fun because nobody actually tested DVR on multiple nodes, so when I did it for the first time and didn't work, I was like, that's interesting, what's going on here? So, quick bug fix, but it's a lot better now for Kilo, but it was interesting to go actually figure out how these work and realize that, you know, we're putting, like, we're at the forefront of OpenStack now with the docs, we're not documenting old stuff, like a lot of the content that currently exists. Sort of we go from here, it is late in the day, so the top one is sort of relevant. Next phase of development, we really need to get the introduction to networking going. We have a lot of people that we find with OpenStack, they've used VMware, they've used virtualization of some sort, they come from storage and how that works, or if they're networking, they've used Cisco, Juniper, Brocade, they have not done networking on Linux, and so namespaces and bridges and all this stuff is just completely foreign to them, and what we really want to do is say, here's the stuff you're used to, here's how it's implemented in Linux, how Neutron uses it. So we want to build on top of all this, and then once you get done with that, go into the scenarios of things you can deploy. And then, of course, beyond that, we want to talk about legacy to HA, a lot of people want to go from Novenet to Neutron, or they want to go from standard Neutron to using DVRL3HA, we want to make sure that that's well documented, and then additional services like VPN as a service, I think lacks pretty much any documentation, so we should probably fix that. And then as we go, it's continuously developed. So we could have chosen to print this book, but the book you print is six months out of date, especially with OpenStack. So the key here is to do everything online. It's run through CI, so when you have something new, it's immediately published. We're not doing this on a release basis yet unless we have something we need to do. And then, you know, check out new, updated, deprecated features all the time, make sure that we're not keeping old stuff around, make sure people know what's new and what they should probably be looking at, and then evaluate all the existing scenarios and to make sure they still work. So we don't want to get this stuff stale. If some major config thing changes between Kilo and Liberty, we want to make sure that the configs actually reference all this stuff, and we specifically tell people, by the way, if you're using Liberty, these things have changed. And then what do you want to see? It's collaborative, so talk to us. Come into the meetings, send us an email, anything you want to kind of say, hey, I use networking in OpenStack and I do this thing and it works. You know, be more than happy to add your stuff to it. So we'll pass it back to Nick to kind of talk about was it successful and then what I'd like to do is kind of just go through the scenarios and the guide real quick and the different pieces that we kind of all contributed to it. Yeah, so was it successful? I would say it definitely was successful in that we have a book and it is useful and the scenarios are all done and that's good. And the methods that we're using are sort of having this specialty team to run this. We are seeing that they're being picked up by other groups. The HA guide is doing the same thing. So if you're an expert in HA and you want to get involved in that, that would be a good place. And also the install guide, which used to be a semi-annual nightmare to get that done, also has its own team. So we're seeing this model kind of pick up, so we're hoping to see more of it. So yeah, things that you can do to participate. Whoops. I'm doing that on purpose. Yeah, I think F5. Whoops, that's not what I wanted to do. There's nothing in there anymore anyway. Matt, sit down. Go sit down. But I think the most important on this slide is I think we believe that we create something great on the networking side. But the most important is to have people to start contributing to it. And there are so many ways to contribute. We don't want you to always start writing code or writing just documentation. We just want you to read it to give you feedback. This is misspelled. This doesn't make sense. You're missing this test case. You're missing this scenario. All these kind of things. We can keep doing the work, or we can actually find who can do it, mostly because I'm almost always late to my deadlines. But sorry, project manager. But the most important is to get more contribution to the community on those areas. And I think we're going to create more marketing around it. Good marketing is not that we're going to try to sell a book or something like that. We just want to make more people aware of the networking guys who are straight away and spread the word about that to exist. The link is actually in the slides as well. So we're going to be very happy we start getting boxed, filed against the networking guy, then get us busy more and more. Definitely. And I think that different people's perspectives is a good lead-in for talking a little bit about the scenarios. For example, we brought Sean in because he had knowledge that none of the rest of us had of running provider networks coming from Comcast. So let's take a minute and talk about the scenarios before we... Well, let's do this first. Does anybody have any questions on the general process before we dive into the actual, here's some nitty-gritty about networking? Going once, going twice. I call that success. I do, I call that a success, that's right. Or everybody's sleeping. Or they're asleep, or they're waiting for the next session. That's actually the particular scenario I wanted to look at was the one that Sean and I sort of collaborated on too, because he got a lot of the base content on knowing how all this worked and then I kind of went and added diagrams to it. So we collaborated on even a different level with that one. So if that's the one you want to peek at or your computer that I was trying to do and thought was open and was not... I can do open stack networking but I can't figure out web browsers. I'm sorry. Yes, okay. So you were trying to get to the actual documentation then. Is that what you're telling me? So for those of you who are not aware, docs.openstack.org, we have... That is sort of the repository of official knowledge that is OpenStack, at least as far as the docs are concerned. And so you can see the networking guide here under Operations and Administration. And you can see here, it's in progress. You know, we want your feedback. So which one... So you can see here there's different... There's different scenarios that are available. Yeah, I'll take 4A for $200. I'll take 4A for $200. Okay, so I can't see it. I just memorized it. Go ahead. So let me just kind of introduce what they are and then we'll go from there and you can pick. Or unless you can read it, go ahead. Well, so we started out by just laying out a couple of scenarios and if you want to go ahead and click on the scenario 4A. Yeah, you want to take a look at the 4A stuff that's in there to give people an idea of kind of why we came up with the format and then Matt Dorn kind of fill in in terms of why we came up with the format we did. Sure, so if you scroll down a little bit and show like one of the first couple of figures, that would be helpful. So basically, I had helped with the team to build a Neutron installation and we had configured Neutron using the provider networking API extension meaning that there was a certain way that the topology had been created, how everything was actually physically wired up to all the compute nodes and the controller plane and everything else. And I had this all in my head and I guess that's one of the biggest things for me with this process is realizing that not everybody eats, sleeps and breathes Neutron networking and has the whole thing in their head. It's actually unhealthy. But this is a problem in general. I think there's a lot of people out there that have a lot of stuff in their head that need to contribute it somewhere. We consider just removing his brain. And it's just that you start to develop these blind spots where you've just been working on it so long that you sort of lose perspective as to somebody who's new to Neutron and everything. There's things that you've just taken for granted and you've integrated into your knowledge that if you were to somehow have amnesia by getting hit with a cinder block or something that's the only way you would ever rediscover the things that you take for granted that you assume that you know and through this process working with Matt and everybody. I remember when we were doing the architecture design guide and Nick was sitting next to me and he was like, well, what's this whole IPv6 thing? Why is it important? And I just had this bug-eyed, like, how could you not know that? Do you not know that the world will come to an end soon? What's IPv6? That was one of those moments where it's something that you've just been working on for so long. It's really important to have people in the process that are new to something or don't know as much as you because that exposes your blind spots. Matt, you have a, this is a long tangent, but Matt probably has a very similar experience to this of trying to educate people and also trying to extract knowledge from the people who know and presenting it in a fashion that's digestible. Yeah, I first learned about OpenStack two years ago and every time I talked to people about Neutron, I was finding out what it is. It wasn't registering, nothing. Like when they were talking to me, I didn't understand what they were saying at all. So it was my job to actually teach Neutron. So I was going to figure out how am I going to do this? So what I did was I needed to find out the story behind Neutron. What's the story here? As a technical trainer, it's my job to find the story and all this technical stuff, get rid of the complexity. And there was a story there. And what I decided to do was I was not, I was okay at networking, but I got a CCNA and then I got my Red Hat certification in Linux. And I think the story of Neutron really starts with Linux networking. If you're familiar with Linux networking and you know all the details specifically of this IP Route 2 package, not to go into specific details, but if you're aware of this and how it works, you realize the real power is in Linux. And if people understand that, then everything becomes much more clear and you start drawing, learning about Linux networking, what you can do with it. And then you move into the Linux bridge scenario, which is the Neutron configuration, and then to open vSwitch. So you start simple, you understand the foundation, and kind of take people on this journey. And like Nick was saying, you said about writers. Yes, I'm an English major. So I can handle tech stuff, but I mean by no means a developer or anything like that, but my job is basically to tell stories. So that's kind of how I approach the Neutron thing. If we scroll down a little bit further to the packet flow, I think this was probably one of the first diagrams that we put together because we sat down and you were like, tell me how a packet starts from a virtual machine and sort of Pachinko machine comes out through the networking layers. Yeah, to put some context in this, I had never done provider networking. I was always the conventional Neutron guy in your tenant networks and they have an L3 router and all this other stuff. And I was like, Sean, I got to draw diagrams for this. I got to figure out how it works. And so we worked together trying to say, okay, how does this stuff go together? So it's kind of neat because I use it as a learning process as well to understand it better. Yes, so it's sort of surprising when I look at it now that that actually all fit in my head. But it was really the diagram process that started to flesh out what the rest of the content that we would write was sort of like drawing out the diagrams first because that really at the end of the day is how it was all stored in my head. And part of that was getting it all out, getting it onto a diagram and then having somebody to ask me questions about like, well, what about this part of it? What about these interfaces? What about how are they addressed and everything out like that? Which V lands? Picture is worth a thousand words. A lot of people have a very difficult time reading text and trying to figure out what's actually happening on their machines with neutrons. What we did here is we said there's a couple of diagrams in the beginning that say, here's everything on your network node. Here's everything on the compute node. Here's the different components. Here's how they're laid out and connected through Linux somehow. And then later on we decided people are also interested to figure out how the traffic flows in each scenario of his north-south traffic from VMs to the internet or back in. And how does east-west traffic work? And even the case of simple east-west, like let's say you have two VMs on the same network that are on different hosts. There's some understanding issues around that as well that I learned about. And so I was like, wow, we really need to document pretty much every case possible that we can to really give people a better idea. And this also helps with troubleshooting because neutron will break. It's not a concept of if. It's just, it's gonna happen. And so you really need to know, I can go back to this diagram and start to figure out, okay, here's where my traffic should be going. Here's where I'm gonna run a TCP dump. Here's where I'm gonna see if these devices exist. And we do a step-by-step in here as well. So in addition to just showing you a picture of it, we say packet starts here, packet goes here, packet does this all the way through. And in the end of each scenario, we have a configuration you can deploy. All the scenarios look the same. They all use the same diagram types. They all have the same structures. You could easily do a side-by-side comparison. And what you'll figure out is a Linux bridge for provider networks is a whole lot easier than DVR. In fact, I had trouble squeezing all the DVR stuff into a diagram that fit on one page without having to print on like C-sized paper. So it was a little frustrating. Okay. So I don't want to cut you off from there, but we have about four minutes left. So I wanted to make sure that we got to questions. So does anybody have any questions? I thought I saw one over here. Do you have a question? Yes. Okay. Do me a favor. Go to that mic there so that we can record your question. That's right. Whoever's got it. Oh, sorry. I wish I could say I could have just handed you the mic. There you go. Sorry about that. Go ahead. I've been to a few neutron sessions. They've got these great diagrams and all these features. Wait, wait, wait. Here. Ask again. I've been to a few neutron sessions today and there's all these great diagrams and new information that's pouring out. Have you got a process to capture all this? Well, that's a good question. See, that's why we have one standing over there. Yeah. So I don't know that we necessarily have a process to capture all of this new stuff. What do you guys... Well, what's interesting is we're kind of ahead of the curve. Well, that's very true. So DVR and L3HA were not really production ready in Juneau, now in Kilo. They are. And so we were kind of ahead of that and tested all this stuff. But that's why we have this guy as our liaison to let us know when new things are there that we need to document. So the right connection is during the summit which is going on right now. Actually, it was going to start in two days. The developers come together and say, okay, we're going to come up with this fancy thing that is called DVR. And they have a bunch of diagrams that we should start using as a baseline for the documentation. However, six or 12 months after that, things totally changed because during the development process and testing process things changed. And those diagrams never get updated. So unfortunately, on our side, we need to come up with like, okay, that was a baseline, but it's not how it's working. Actually, I remember Matt saying like, hey, I'm reading this. That's supposed to work in this. And it's totally different. And unfortunately, it's this process in the open source community. Somebody start testing something. I start making changes because it's the only way to actually make it work. So we need to do a lot of reverse engineering along the work. And we're trying to fix it. We're trying to get on board. So part of the work that I'm doing on the Neutron team is every time that there is something that is going to change logically or the functionality of the API or something, we have a doc impact, which means we need to write documentation for that. Sorry. The difference between our doc impacts and a lot of times people just throw things over the fence as devs or like docs will figure it out. And we couldn't because it was just docs and I don't understand what that little piece of code does. But now I can go back to Edgar and say, hey, somebody threw this over the fence in our direction. We need to know what to deal with this. Exactly. I just wanted to know. One thing that I found a bit confusing when I was reading documentation on this, so yours, but just documentation in general, was that they're always using private networks. So you don't really know. So when you're looking at it, is this a private network or is this like a supposed to be the public network? So I'm wondering if there's some sort of, maybe in the future, some sort of convention like 172.29 will always be the public network. So there is already an IPv4 subnet that is allocated for documentation purposes. And there's also a similar one for the IPv6 part. And one of the things we're going to have to go through is ensure that those correct prefixes are being used in our documentation because of those concerns that you've mentioned. So when we do a, you know, like a tenant network, which is isolated, obviously still use the RFC 1918. But then what we need to do is we need to go and use the IPv4 prefix to say, you know, this is a, this is the documentation prefix. This would be what your external network connectivity would be. You know, like, so just replace it with, I forget honestly. And if you look at the diagrams that we have in here, we use a consistent color scheme for what things are. And if it's, I think it's teal or something is always an external network. So you can see where this external network touches your system. And then the tenant networks are their own colors. And they stay that way throughout every scenario. So you can see, and we're trying to use, when something should be public or could be, we do use one of these RFC spaces where you can see that there should be an external, otherwise we wind up using an RFC 1918, like a 10 dot or 172. So you notice that they have all of that in their head. Well, so for example, the first app, we, in the networking section. Which we're talking about tomorrow at, what time? Tomorrow. Come back tomorrow. In that part, in that section of the first app documentation, I actually go and say, here's the prefix that is used for the public, your public connectivity. And then here's the prefixes that are used for your RFC 1918 space, meaning your private tenant networks. So I did, you know, I also saw that as well when I was reading neutron documentation, when I was learning. And that also was a frustrating thing. So I've tried to keep, remember that and fix both. You know, it's a good idea too. Maybe we should write this in the networking guide. By the way, here's the conventions we're using. It's an excellent idea. So you can file a bug. Well, thank you. So you have now contributed, you have now contributed to the process. It's like a one-liner, right? See, there you go. Good job. Good job. Thank you. Any other questions? All right. Thank you. Congratulations to you all. Thank you. Thank you all very much.