<div dir="ltr"><div><div><div><div>Hi!<br><br></div>I mostly agree with Igor, GET request should not produce changes (i.e. allocate VIPs).<br><br>> VIP allocation should be performed when we run deployment.<br><br></div>I want to give an explanation here. We have a ticket for 8.0 to give an ability to set arbitrary addresses for VIPs. So, at least some of VIPs can be set via API calls. And auto-allocation of addresses for VIPs should be done just before deployment. The only concern here, whether we need a VIP for net-checker. We could allocate VIPs on net-checker request then also (it is PUT request).<br></div><div><br></div>AFAIC, we also need to provide an ability to run CheckBeforeDeployment task separately (only within ApplyChanges for now). It will help the user to diagnose different problems. It seems to be a subject for another discussion/ticket though.<br><br></div>Thanks,<br><div><br><div><div><br><br></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Aleksey Kasatkin
<br><br></div></div></div>
<br><div class="gmail_quote">On Mon, Oct 19, 2015 at 11:28 AM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Roman,<br>
<span class=""><br>
> Not assign addresses to VIPs is a network configuration is being<br>
> serialized for API output.<br>
<br>
</span>AFAIK, that's not truth. Fuel UI and OSTF relies only on *public* VIP.<br>
So we can keep only *public* VIP, and do not assign / show others.<br>
<span class=""><br>
> Check number of IP addresses wherever it is possible to "spoil" network<br>
> configuration: when a role get’s assigned to a node, when network<br>
> changes or network templates are applied.<br>
<br>
</span>It won't work that way. What if you enable plugin when all roles are<br>
assigned? What if you change networks, and now it's not enough IPs? Or<br>
what if enable plugin that requires 5 VIPs in public network by<br>
default, and it's not enough. But by using network templates you<br>
assign this netrole to management network?<br>
<br>
>From what I can say the proposed approach requires to put checks<br>
here-and-there around the code. Let's do not overcomplicate things<br>
without real need.<br>
<br>
So let me share my thoughts regarding this issue.<br>
<br>
* We shouldn't *allocate* VIPs when we make GET request on network<br>
configuration handler. It should return only *already allocated* VIPs<br>
and no more.<br>
* VIP allocation should be performed when we run deployment.<br>
* Before deployment checks should fail, if there's not enough VIPs or<br>
other resources. So users fix them, and try again.<br>
* Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and<br>
it's safe to return allocated VIPs on that stage.<br>
<br>
So what do you think guys?<br>
<br>
Thanks,<br>
Igor<br>
<div><div class="h5"><br>
On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko <<a href="mailto:me@romcheg.me">me@romcheg.me</a>> wrote:<br>
> Hi folks!<br>
><br>
> I’ve been discussing several bugs [1-3] with some folks and noticed that they share the same root cause which is that network serialization fails, if there’s not enough IP addresses in all available ranges of one of the available networks to assign them to all VIPs. There are several possible solutions for this issue:<br>
><br>
> a. Not assign addresses to VIPs is a network configuration is being serialized for API output.<br>
> A lot of external tools and modules, i. e., OSTF, rely on that information so this relatively small change in Nailgun will require big cross-components changes. Therefore this change can only be done as a feature but it seems to be the way this issue must be fixed.<br>
><br>
> b. Leave some VIPs without IP addresses<br>
> If network configuration is generated for API output it is possible to leave some VIPs without IP addresses assigned. This will only create more mess around Nailgun and bring more issues that it will resolve.<br>
><br>
> c. Check number of IP addresses wherever it is possible to "spoil" network configuration: when a role get’s assigned to a node, when network changes or network templates are applied.<br>
><br>
><br>
> The proposal is to follow [c] as a fast solution and file a blueprint for [a]. Opinions?<br>
><br>
><br>
> 1 <a href="https://bugs.launchpad.net/fuel/+bug/1487996" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1487996</a><br>
> 2 <a href="https://bugs.launchpad.net/fuel/+bug/1500394" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1500394</a><br>
> 3 <a href="https://bugs.launchpad.net/fuel/+bug/1504572" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1504572</a><br>
><br>
><br>
> - romcheg<br>
><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>
<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>
</blockquote></div><br></div>