Let's summarize what we have by now.
1/ We agreed on removing *VIP allocation* code from GET
network_configuration API handler. Already allocated VIPs should be
returned by this call though.
2/ We agreed on checking whether it's enough IP addressed in the pool
as a part of Verify Network
> Then we should close  as invalid, shoudn’t we?
AFAIC, no. We should check whether there is enough IPs for nodes /
VIPs with current network configuration.
I'd propose to add a handler for allocation of VIPs if VIPs can be useful
I'm not sure what are the cases.
Then we should close  as invalid, shoudn’t we?
> 20 жовт. 2015 р. о 15:55 Igor Kalnitsky написав(ла):
>> This behavior is actually described in . Should we allocate
>> VIPs on network check as well?
> No, we shouldn't. We should check whether it's
My concern here is that there is also a Network check feature that according to
its name should check things like whether or not there’s enough IP addresses in
all ranges in a network. The problem is that it may be run at any time, even
when VIPs are not yet allocated. From a user-side the
> but the problem lies that VIP's need to already be allocated.
Why? Fuel doesn't use them on this stage.
> They need to be allocated on network update, or when a node role requiring
> one is added to the environment.
It looks like either you or me misunderstood something. AFAIK, node
> This behavior is actually described in . Should we allocate
> VIPs on network check as well?
No, we shouldn't. We should check whether it's enough IPs for nodes /
VIPs with current network configuration, but no more.
On Tue, Oct 20, 2015 at 4:54 PM, Igor Kalnitsky
On Mon, Oct 19, 2015 at 9:29 AM Igor Kalnitsky
> Hi Roman,
> > Not assign addresses to VIPs is a network configuration is being
> > serialized for API output.
> AFAIK, that's not truth. Fuel UI and OSTF relies only on *public* VIP.
> So we can keep only
I mostly agree with Igor, GET request should not produce changes (i.e.
> VIP allocation should be performed when we run deployment.
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
Thank you for input.
> We have a ticket for 8.0 to give an ability to set arbitrary addresses for
That shouldn't affect proposed approach. The main idea is to return
*allocated VIPs* but *do not allocate* them implicitly.
> we also need to provide an ability to run
> Not assign addresses to VIPs is a network configuration is being
> serialized for API output.
AFAIK, that's not truth. Fuel UI and OSTF relies only on *public* VIP.
So we can keep only *public* VIP, and do not assign / show others.
> Check number of IP addresses wherever it is
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
Mail list logo