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 workflow may look a little wrong:
1. Check network => get "Everything is fine" 2. Right after that press Apply Changes => get "Network configuration is bad" This behavior is actually described in [1]. Should we allocate VIPs on network check as well? 1. https://bugs.launchpad.net/fuel/+bug/1487996 - romcheg > 19 жовт. 2015 р. о 18:28 Igor Kalnitsky <ikalnit...@mirantis.com> написав(ла): > > 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. > * VIP allocation should be performed when we run deployment. > * Before deployment checks should fail, if there's not enough VIPs or > other resources. So users fix them, and try again. > * Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and > it's safe to return allocated VIPs on that stage. > > So what do you think guys? > > Thanks, > Igor > > On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko <m...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
