[openstack-dev] [Fuel] Assigning VIPs on network config serialization

Andrew Woodward awoodward at mirantis.com
Mon Oct 19 21:00:09 UTC 2015


On Mon, Oct 19, 2015 at 9:29 AM Igor Kalnitsky <ikalnitsky at mirantis.com>
wrote:

> 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 *public* VIP, and do not assign / show others.
>
> > 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.
>
> It won't work that way. What if you enable plugin when all roles are
> assigned? What if you change networks, and now it's not enough IPs? Or
> what if enable plugin that requires 5 VIPs in public network by
> default, and it's not enough. But by using network templates you
> assign this netrole to management network?
>
> From what I can say the proposed approach requires to put checks
> here-and-there around the code. Let's do not overcomplicate things
> without real need.
>
> So let me share my thoughts regarding this issue.
>
> * We shouldn't *allocate* VIPs when we make GET request on network
> configuration handler. It should return only *already allocated* VIPs
> and no more.


I agree, GET handler should not allocate vips, but the problem lies that
VIP's need to already be allocated. They need to be allocated on network
update, or when a node role requiring one is added to the environment. Not
knowing the address until serialization for deployment is too late. The
user needs feedback on the network page. 1) They need to know how many
vip's are on each network (eventually they should be able to set these, but
that is slightly off topic) 2) When saving a change they need to know that
they have ENOUGH IP's for ALL of the currently configured VIPs and Nodes.
Clicking deploy and getting "You don't have enough addresses start over"
with out any feedback on why is not valuable to the user and they go back
to settings pages, count their nodes, and then are "yup, there are enough,
fuel is broken".

Further compacting the issue, now plugins and tasks are going to start to
be able to configure more VIP addresses. In this case it will become even
more confusing as to how many VIP addresses (and from which network) they
come from with out good feedback up front. The only way we can do this is
generating the VIP addresses as soon as we have enough data for them, not
at deployment serialization.



* VIP allocation should be performed when we run deployment.
>
No, see above

> * Before deployment checks should fail, if there's not enough VIPs or
> other resources. So users fix them, and try again.
>
No, see above, its a bad User eXperience (UX) and needs to be stopped. This
is why Roman raised the issue.

> * Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and
> it's safe to return allocated VIPs on that stage.
>
No, Again, this is too late.

>
> So what do you think guys?
>
> Thanks,
> Igor
>
> On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko <me at romcheg.me>
> wrote:
> > Hi folks!
> >
> > 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:
> >
> > a. Not assign addresses to VIPs is a network configuration is being
> serialized for API output.
> > 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.
> >
> > b. Leave some VIPs without IP addresses
> > 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.
> >
> > 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.
> >
> >
> > The proposal is to follow [c] as a fast solution and file a blueprint
> for [a]. Opinions?
> >
> >
> > 1 https://bugs.launchpad.net/fuel/+bug/1487996
> > 2 https://bugs.launchpad.net/fuel/+bug/1500394
> > 3 https://bugs.launchpad.net/fuel/+bug/1504572
> >
> >
> > - romcheg
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151019/3dd11f77/attachment.html>


More information about the OpenStack-dev mailing list