<div dir="ltr">Hi Aleksey,<div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>What is the status of making networking part replaceable? As I know, [0] is in progress. Are there any other activities in progress (about API, serialization for orchestrator, network verification)? Do we have specs on review (I know about this one: [1]) ?<br></div><div><br></div></div></div></div></blockquote><div> </div><div>AFAIK there are no other activities in progress right now.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>As I know, [0] is about separate storage service for networking related information (from what I've seen), not about moving all network-related code. Please correct me if it's not true.<br></div></div></div></div></blockquote><div><br></div><div>You are correct. The intent was to end up with a separate network storage service and network manager as a client of this service (where appropriate).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br>AFAIC, [0] can be combined with moving of network part into extension (API, serialization). So, extension could use this storage. Network verification (net-checker) depends on networking data and it uses the same RPC so it can be more difficult to move its setup and results acquisition from Nailgun into extension.<br>I'm for networking as extension as it was done for "volume manager" already.<br><br></div></div></div></div></blockquote><div><br>I agree that moving network manager into an extension would be good. I think we'll need some discussion around that though. NetworkManager does a lot and some of it can be pushed off to a separate service but some will always be tied to Nailgun. I'm not sure how or if that will impact moving it into an extension.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div>Please expand this a bit: "Reuse Neutron API with additional plugins/extensions to provide for us a way to also store bonds/nics related information."<br></div>As I understand, it's rather specific stuff and will cover very small part of the whole task. And as 2.1 is in progress already, 2.3 seems to be rejected..?<br><br></div></div></blockquote><div><br></div><div>I originally created a simple PoC (2.1) just to test out the idea. The Nailgun side of this work done since doesn't have any dependency on that PoC. We can freely change directions. Neutron handles a lot of what Nailgun cares about (networks, subnets, IP allocation, etc.) so I'm currently investigating it as an option.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>I'd like to participate in design discussions. Please add me into meetings.</div></div></blockquote><div><br></div><div>I will make sure you're included. Your input would be greatly appreciated.</div><div><br></div><div>Thanks,</div><div>Ryan</div></div></div></div></div>