<div dir="ltr"><div><div><div><div>Hey Adam,<br><br></div>in Fuel we have the following option (checkbox) on Network Setting tab:<br><br>Assign public network to all nodes<br><span class=""><span>When disabled, public network will be assigned to controllers only<br><br></span></span></div><span class=""><span>So if you uncheck it (by default it's unchecked) then public network and 'br-ex' will exist on controllers only. Other nodes won't even have "Public" network on node interface configuration UI.<br><br></span></span></div><span class=""><span>Regards,<br></span></span></div><span class=""><span>Alex<br></span></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 25, 2016 at 9:43 AM, Adam Heczko <span dir="ltr"><<a href="mailto:aheczko@mirantis.com" target="_blank">aheczko@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">Hello Alex,<div>I have a question about the proposed changes.</div><div>Is it possible to introduce new vlan and associated bridge only for controllers?</div><div>I think about DMZ use case and possibility to expose public IPs/VIP and API endpoints on controllers on a completely separate L2 network (segment vlan/bridge) not present on any other nodes than controllers.</div><div>Thanks.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko <span dir="ltr"><<a href="mailto:adidenko@mirantis.com" target="_blank">adidenko@mirantis.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div>Hi folks,<br><br></div>we had to revert those changes [0] since it's impossible to propery handle two different netconfig tasks for multi-role nodes. So everything stays as it was before - we have single task 'netconfig' to configure network for all roles and you don't need to change anything in your plugins. Sorry for inconvenience.<br><br>Our current plan for fixing network idempotency is to keep one task but change 'cross-depends' parameter to yaql_exp. This will allow us to use single 'netconfig' task for all roles but at the same time we'll be able to properly order it: netconfig on non-controllers will be executed only aftetr 'virtual_ips' task.<br><br></div>Regards,<br></div>Alex<br><br>[0] <a href="https://review.openstack.org/#/c/320530/" target="_blank">https://review.openstack.org/#/c/320530/</a><br><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko <span dir="ltr"><<a href="mailto:adidenko@mirantis.com" target="_blank">adidenko@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><div>Hi all,<br><br></div><div>please be aware that now we have two netconfig tasks (in Fuel 9.0+):<br></div><div><br>- netconfig-controller - executed on controllers only<br></div><div>- netconfig - executed on all other nodes<br><br></div><div>puppet manifest is the same, but tasks are different. We had to do this [0] in order to fix network idempotency issues [1].<br><br>So if you have 'netconfig' requirements in your plugin's tasks, please make sure to add 'netconfig-controller' as well, to work properly on controllers.<br></div><div><br></div>Regards,<br></div>Alex<br><div><div><div><br>[0] <a href="https://bugs.launchpad.net/fuel/+bug/1541309" target="_blank">https://bugs.launchpad.net/fuel/+bug/1541309</a><br>[1] <a href="https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z" target="_blank">https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z</a><br></div></div></div></div>
</blockquote></div><br></div>
</div></div><br></div></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Adam Heczko</div><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Security Engineer @ Mirantis Inc.</div></div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>