<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Apr 11, 2014, at 12:35 AM, Andrey Danin <<a href="mailto:adanin@mirantis.com">adanin@mirantis.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 9, 2014 at 4:22 AM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Looks like it falls into two parts: Fuel & Neutron requirements.</div><div><br></div><div>Use case, as far as I understand, is following: user doesn't have one large range of publicly routable IP addresses for environment, and has multiple L3 ranges instead.</div>
<div><br></div><div>So for Fuel it means:</div><div><ol><li>We should not waste public IPs for compute nodes nodes if we don't need them there (Neutron doesn't need it, only required for nova-network in multi-host mode). I think it should be covered by <a href="https://blueprints.launchpad.net/fuel/+spec/advanced-networking" target="_blank">https://blueprints.launchpad.net/fuel/+spec/advanced-networking</a></li>
</ol></div></div></blockquote><div> We can do that when we introduce a role-based network assignment.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div><ol>
<li>If we use public network then only for OpenStack REST API services, we should be fine with one single IP range, do we?</li></ol></div></div></blockquote><div>Yes. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><ol><li>Floating network, which is external in Neutron terms, can be large waste of IPs for VMs. So it's impossible that in large clusters there is gonna be single L3 which would cover it. That means, Fuel should allow to have multiple L3 external networks per OpenStack environment, in theory they can be even in different L2.</li>
</ol></div></blockquote><div>Our complex network setup (many bridges and many patches) allows us to concatenate multiple L3-networks into one L2-segment. And theoreticaly Neutron can manage multiple external networks in this setup. But we need to test it. <br></div></div></div></div></blockquote><div><br></div><div>also we should be able provide multiple floating networks (each in different L2 network) like on diagram </div><div><a href="https://drive.google.com/file/d/0B_Tv5g8RQZt1R3NIUEZtYkhEVVk/edit?usp=sharing">https://drive.google.com/file/d/0B_Tv5g8RQZt1R3NIUEZtYkhEVVk/edit?usp=sharing</a></div><div>It will be useful for hybrid (private/public) cloud.</div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ol>
</ol></div>I had a short discussion with Maru & Mark in IRC, it looks like we need in Neutron:<div><ol><li>It should be possible to have multiple L3 subnets for external network</li><li>It is unlikely that we will need to have more than one subnet serving by single Neutron server, but we might in theory..</li>
</ol><div>Alexander, please take a look if I treated your initial blueprint in a right way.</div><div><br></div><div>Thanks,</div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Apr 8, 2014 at 7:53 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Mike,<div><br></div><div>For all neutron-related fuel developments please feel free to reach to to the neutron team for any help you might need either by using the ML or pinging people in #openstack-neutron.</div>
<div>Regarding the fuel blueprints you linked in your first post, I am looking in particular at <a href="https://blueprints.launchpad.net/fuel/+spec/separate-public-floating" target="_blank">https://blueprints.launchpad.net/fuel/+spec/separate-public-floating</a></div>
<div><br></div><div>I am not entirely sure of what are the semantics of 'public' and 'floating' here, but I was wondering if this would be achievable at all with the current neutron API, since within a subnet CIDR there's no 'qualitative' distinction of allocations pools; so it would not be possible to have a 'public' IP pool and a 'floating' IP pool in the same L3 segment.</div>
<div><br></div><div>Also, regarding nova gaps, it might be worth noting that Mark McClain (markmcclain) and Brent Eagles (beagles) are keeping track of current feature/testing/quality gaps and also covering progress for the relevant work items.</div>
<div><br></div><div>Regards,</div><div>Salvatore</div></div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On 8 April 2014 14:46, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Great, thanks Assaf.<div><br></div><div>I will keep following it. I've added a link to this bp on this page: <a href="https://wiki.openstack.org/wiki/NovaNeutronGapHighlights#Multi-Host" target="_blank">https://wiki.openstack.org/wiki/NovaNeutronGapHighlights#Multi-Host</a>, might help people to get the status.</div>
</div><div class="gmail_extra"><div><br><br><div class="gmail_quote">On Mon, Apr 7, 2014 at 11:37 AM, Assaf Muller <span dir="ltr"><<a href="mailto:amuller@redhat.com" target="_blank">amuller@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
<br>
----- Original Message -----<br>
> Hi all,<br>
> we had a number of discussions last week in Moscow, with participation of<br>
> guys from Russia, Ukraine and Poland.<br>
> That was a great time!! Thanks everyone who participated.<br>
><br>
> Special thanks to Przemek for great preparations, including the following:<br>
> <a href="https://docs.google.com/a/mirantis.com/presentation/d/115vCujjWoQ0cLKgVclV59_y1sLDhn2zwjxEDmLYsTzI/edit#slide=id.p" target="_blank">https://docs.google.com/a/mirantis.com/presentation/d/115vCujjWoQ0cLKgVclV59_y1sLDhn2zwjxEDmLYsTzI/edit#slide=id.p</a><br>
><br>
> I've searched over blueprints which require update after meetings:<br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/multiple-cluster-networks" target="_blank">https://blueprints.launchpad.net/fuel/+spec/multiple-cluster-networks</a><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-multiple-l3-agents" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-multiple-l3-agents</a><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-storage-networks" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-storage-networks</a><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/separate-public-floating" target="_blank">https://blueprints.launchpad.net/fuel/+spec/separate-public-floating</a><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/advanced-networking" target="_blank">https://blueprints.launchpad.net/fuel/+spec/advanced-networking</a><br>
><br>
> We will need to create one for UI.<br>
><br>
> Neutron blueprints which are in the interest of large and thus complex<br>
> deployments, with the requirements of scalability and high availability:<br>
> <a href="https://blueprints.launchpad.net/neutron/+spec/l3-high-availability" target="_blank">https://blueprints.launchpad.net/neutron/+spec/l3-high-availability</a><br>
> <a href="https://blueprints.launchpad.net/neutron/+spec/quantum-multihost" target="_blank">https://blueprints.launchpad.net/neutron/+spec/quantum-multihost</a><br>
><br>
> The last one was rejected... there is might be another way of achieving same<br>
> use cases? Use case, I think, was explained in great details here:<br>
> <a href="https://wiki.openstack.org/wiki/NovaNeutronGapHighlights" target="_blank">https://wiki.openstack.org/wiki/NovaNeutronGapHighlights</a><br>
> Any thoughts on this?<br>
><br>
<br>
</div><a href="https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr" target="_blank">https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr</a><br>
This is the up the date blueprint, called "Distributed virtual<br>
router", or DVR. It's in early implementation reviews and is<br>
targeted for the Juno release.<br>
<div><br>
> Thanks,<br>
> --<br>
> Mike Scherbakov<br>
> #mihgen<br>
><br>
</div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div></div><span><font color="#888888">-- <br><div dir="ltr"><div>Mike Scherbakov</div><div>#mihgen</div></div>
</font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Mike Scherbakov</div><div>#mihgen</div></div>
</div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Andrey Danin<br><a href="mailto:adanin@mirantis.com" target="_blank">adanin@mirantis.com</a><br>skype: gcon.monolake<br>
</div></div>
</blockquote></div><br></body></html>