<div dir="ltr"><div><div><div>Hi,<br><br></div>you don't need to change anything in your plugin, we still have the same netconfig.pp task on all nodes even after bugfix.<br><br></div>Regards,<br></div>Alex<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 7, 2016 at 8:21 AM, Igor Zinovik <span dir="ltr"><<a href="mailto:izinovik@mirantis.com" target="_blank">izinovik@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><div><div>  Hello,<br><br></div>Aleksandr, one simple question: do I as a plugin developer for upcoming Fuel 9.0 have<br></div>to worry about these network-related changes or not? HCF is approaching, but patch<br></div>that you mentioned (<a href="https://review.openstack.org/#/c/324307/" target="_blank">342307</a>) is still not merged. Do I need to spend time on understanding<br></div>it and change <a href="https://github.com/openstack/fuel-plugin-nsxv/blob/bab9541d9f13cf80a4796117483e56e94f3a4c09/deployment_tasks.yaml#L1-L10" target="_blank">plugins deployment tasks</a> according to the netconfig.pp refactoring?<div><div class="h5"><br><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 6 June 2016 at 11:12, 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><div>Hi,<br><br></div>a bit different patch is on review now [0]. Instead of silently replacing default gateway on the fly in netconfig.pp task it's putting new default gateway into Hiera. Thus we'll have idempotency for subsequent netconfig.pp runs even on Mongo roles. Also we'll have consistent network configuration data in Hiera which any plugin can rely on.<br><br></div><div>I've built a custom ISO with this patch and run a set of custom tests on it to cover multi-role and multi-rack cases [1] plus BVT - everything worked fine.<br></div><div><br>Please feel free to review and comment the patch [0].<br><br></div>Regards,<br></div>Alex<br><div><div><br>[0] <a href="https://review.openstack.org/324307" target="_blank">https://review.openstack.org/324307</a><br>[1] <a href="http://paste.openstack.org/show/508319/" target="_blank">http://paste.openstack.org/show/508319/</a><br></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 1, 2016 at 4:47 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><div>Hi,<br><br></div>YAQL expressions support for task dependencies has been added to Nailgun [0]. So now it's possible to fix network configuration idempotency issue without introducing new 'netconfig' task [1]. There will be no problems with loops in task graph in such case (tested on multiroles, worked fine). When we deprecate role-based deployment (even emulated), then we'll be able to remove all those additional conditions from manifests and remove 'configure_default_route' task completely. Please feel free to review and comment the patch [1].<br><br></div>Regards,<br></div>Alex<br><br>[0] <a href="https://review.openstack.org/#/c/320861/" target="_blank">https://review.openstack.org/#/c/320861/</a><br>[1] <a href="https://review.openstack.org/#/c/322872/" target="_blank">https://review.openstack.org/#/c/322872/</a><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 25, 2016 at 10:39 AM, Simon Pasquier <span dir="ltr"><<a href="mailto:spasquier@mirantis.com" target="_blank">spasquier@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><div>Hi Adam,<br></div>Maybe you want to look into network templates [1]? Although the documentation is a bit sparse, it allows you to define flexible network mappings.<br></div>BR,<br></div>Simon<br>[1] <a href="https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates" target="_blank">https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates</a><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 25, 2016 at 10:26 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">Thanks Alex, will experiment with it once again although AFAIR it doesn't solve thing I'd like to do.<div>I'll come later to you in case of any questions.<br><div><div><br></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 25, 2016 at 10:00 AM, 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><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><span>When disabled, public network will be assigned to controllers only<br><br></span></span></div><span><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><span>Regards,<br></span></span></div><span><span>Alex<br></span></span></div><div><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>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><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><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>
</div></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><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>
</div>
</div></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>
</div></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>
</div></div></blockquote></div><br></div>
</div></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></div></div></div></div></div></div></div></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>