Open Stack

Aleksey,

Thank you for input.

> We have a ticket for 8.0 to give an ability to set arbitrary addresses for VIPs

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 CheckBeforeDeployment task separately

That's another story. Let's keep close to main subject, and a bunch of
issues mentioned by Roman,

Thanks,
Igor


On Mon, Oct 19, 2015 at 8:05 PM, Aleksey Kasatkin
<akasatkin at mirantis.com> wrote:
> Hi!
>
> I mostly agree with Igor, GET request should not produce changes (i.e.
> allocate VIPs).
>
>> 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 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).
>
> 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.
>
> Thanks,
>
>
>
>
> Aleksey Kasatkin
>
>
> On Mon, Oct 19, 2015 at 11:28 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.
>> * 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 <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
>
>
>
> __________________________________________________________________________
> 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
>