Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

[Aleksey Kasatkin]

We have more generic ticket: https://bugs.launchpad.net/fuel/+bug/1354803
and corresponding CR: https://review.openstack.org/#/c/245941/

Aleksey Kasatkin


On Fri, Nov 20, 2015 at 11:24 AM, Aleksey Kasatkin 
wrote:

> It's not about Public networks only. There can be the same problem with
> other networks as well.
> It's required to check all the networks (across all node groups).
> But it is done just for Public network now (and VIPs for plugins are not
> taken into account).
>
>
> Aleksey Kasatkin
>
>
> On Fri, Nov 20, 2015 at 12:04 AM, Andrew Woodward 
> wrote:
>
>> The high value of the bug here reflects that the error message is wrong.
>> From a UX side we could maybe even justify this as Critical. The error
>> message must reflect the correct quantity of addresses required.
>>
>>
>> On Tue, Nov 17, 2015 at 1:31 PM Roman Prykhodchenko 
>> wrote:
>>
>>> Folks, we should resurrect this thread and find a consensus.
>>>
>>> 1 вер. 2015 р. о 15:00 Andrey Danin  написав(ла):
>>>
>>>
>>> +1 to Igor.
>>>
>>> It's definitely not a High bug. The biggest problem I see here is a
>>> confusing error message with a wrong number of required IPs. AFAIU we
>>> cannot fix it easily now so let's postpone it to 8.0 but change a message
>>> itself [0] in 7.0.
>>>
>>> We managed to create an error that returns '7', when there are 8
>> available, but 9 are required, at some level we knew that we came up short
>> or we'd just have some lower level error caught here.
>>
>>>
>>> [0]
>>> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/task/task.py#L1160-L1163
>>>
>>> On Tue, Sep 1, 2015 at 1:39 PM, Igor Kalnitsky 
>>> wrote:
>>>
 Hello,

 My 5 cents on it.

 I don't think it's really a High or Critical bug for 7.0. If there's
 not enough IPs the CheckBeforeDeploymentTask will fail. And that's
 actually Ok, it may fail by different reason without starting actual
 deployment (sending message to Astute).

 But I agree it's kinda strange that we don't check IPs during network
 verification step. The good fix in my opinion is to move this check
 into network checker (perhaps keep it here either), but that
 definitely shouldn't be done in 7.0.

 Thanks,
 Igor


 On Mon, Aug 31, 2015 at 2:54 PM, Roman Prykhodchenko 
 wrote:
 > Hi folks!
 >
 > Recently a problem that network check does not tell whether there’s
 enough IP addresses in a public network [1] was reported. That check is
 performed by CheckBeforeDeployment task, but there is two problems that
 happen because this verification is done that late:
 >
 >  - A deployment fails, if there’s not enough addresses in specified
 ranges
 >  - If a user wants to get network configuration they will get an error
 >
 > The solution for this problems seems to be easy and a straightforward
 patch [2] was proposed. However, there is a hidden problem which is that
 patch does not address which is that installed plugins may reserve VIPs for
 their needs. The issue is that they do it just before deployment and so
 it’s not possible to get those reservations when a user wants to check
 their network set up.
 >
 > The important issue we have to address here is that network
 configuration generator will fail, if specified ranges don’t fit all VIPs.
 There were several proposals to fix that, I’d like to highlight two of 
 them:
 >
 >  a) Allow VIPs to not have an IP address assigned, if network config
 generator works for API output.
 >  That will prevent GET requests from failure, but since IP
 addresses for VIPs are required, generator will have to fail, if it
 generates a configuration for the orchestrator.
 >  b) Add a release note that users have to calculate IP addresses
 manually and put sane ranges in order to not shoot their own legs. Then
 it’s also possible to change network verification output to remind users to
 check the ranges before starting a deployment.
 >
 > In my opinion we cannot follow (a) because it only masks a problem
 instead of providing a fix. Also it requires to change the API which is not
 a good thing to do after the SCF. If we choose (b), then we can work on a
 firm solution in 8.0 and fix the problem for real.
 >
 >
 > P. S. We can still merge [2], because it checks, if IP ranges can at
 least fit the basic configuration. If you agree, I will update it soon.
 >
 > [1] https://bugs.launchpad.net/fuel/+bug/1487996
 > [2] https://review.openstack.org/#/c/217267/
 >
 >
 >
 > - romcheg
 >
 >
 >
 >
 >
 __
 > OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

[Aleksey Kasatkin]

It's not about Public networks only. There can be the same problem with
other networks as well.
It's required to check all the networks (across all node groups).
But it is done just for Public network now (and VIPs for plugins are not
taken into account).


Aleksey Kasatkin


On Fri, Nov 20, 2015 at 12:04 AM, Andrew Woodward  wrote:

> The high value of the bug here reflects that the error message is wrong.
> From a UX side we could maybe even justify this as Critical. The error
> message must reflect the correct quantity of addresses required.
>
>
> On Tue, Nov 17, 2015 at 1:31 PM Roman Prykhodchenko  wrote:
>
>> Folks, we should resurrect this thread and find a consensus.
>>
>> 1 вер. 2015 р. о 15:00 Andrey Danin  написав(ла):
>>
>>
>> +1 to Igor.
>>
>> It's definitely not a High bug. The biggest problem I see here is a
>> confusing error message with a wrong number of required IPs. AFAIU we
>> cannot fix it easily now so let's postpone it to 8.0 but change a message
>> itself [0] in 7.0.
>>
>> We managed to create an error that returns '7', when there are 8
> available, but 9 are required, at some level we knew that we came up short
> or we'd just have some lower level error caught here.
>
>>
>> [0]
>> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/task/task.py#L1160-L1163
>>
>> On Tue, Sep 1, 2015 at 1:39 PM, Igor Kalnitsky 
>> wrote:
>>
>>> Hello,
>>>
>>> My 5 cents on it.
>>>
>>> I don't think it's really a High or Critical bug for 7.0. If there's
>>> not enough IPs the CheckBeforeDeploymentTask will fail. And that's
>>> actually Ok, it may fail by different reason without starting actual
>>> deployment (sending message to Astute).
>>>
>>> But I agree it's kinda strange that we don't check IPs during network
>>> verification step. The good fix in my opinion is to move this check
>>> into network checker (perhaps keep it here either), but that
>>> definitely shouldn't be done in 7.0.
>>>
>>> Thanks,
>>> Igor
>>>
>>>
>>> On Mon, Aug 31, 2015 at 2:54 PM, Roman Prykhodchenko 
>>> wrote:
>>> > Hi folks!
>>> >
>>> > Recently a problem that network check does not tell whether there’s
>>> enough IP addresses in a public network [1] was reported. That check is
>>> performed by CheckBeforeDeployment task, but there is two problems that
>>> happen because this verification is done that late:
>>> >
>>> >  - A deployment fails, if there’s not enough addresses in specified
>>> ranges
>>> >  - If a user wants to get network configuration they will get an error
>>> >
>>> > The solution for this problems seems to be easy and a straightforward
>>> patch [2] was proposed. However, there is a hidden problem which is that
>>> patch does not address which is that installed plugins may reserve VIPs for
>>> their needs. The issue is that they do it just before deployment and so
>>> it’s not possible to get those reservations when a user wants to check
>>> their network set up.
>>> >
>>> > The important issue we have to address here is that network
>>> configuration generator will fail, if specified ranges don’t fit all VIPs.
>>> There were several proposals to fix that, I’d like to highlight two of them:
>>> >
>>> >  a) Allow VIPs to not have an IP address assigned, if network config
>>> generator works for API output.
>>> >  That will prevent GET requests from failure, but since IP
>>> addresses for VIPs are required, generator will have to fail, if it
>>> generates a configuration for the orchestrator.
>>> >  b) Add a release note that users have to calculate IP addresses
>>> manually and put sane ranges in order to not shoot their own legs. Then
>>> it’s also possible to change network verification output to remind users to
>>> check the ranges before starting a deployment.
>>> >
>>> > In my opinion we cannot follow (a) because it only masks a problem
>>> instead of providing a fix. Also it requires to change the API which is not
>>> a good thing to do after the SCF. If we choose (b), then we can work on a
>>> firm solution in 8.0 and fix the problem for real.
>>> >
>>> >
>>> > P. S. We can still merge [2], because it checks, if IP ranges can at
>>> least fit the basic configuration. If you agree, I will update it soon.
>>> >
>>> > [1] https://bugs.launchpad.net/fuel/+bug/1487996
>>> > [2] https://review.openstack.org/#/c/217267/
>>> >
>>> >
>>> >
>>> > - 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 

Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

[Andrew Woodward]

The high value of the bug here reflects that the error message is wrong.
>From a UX side we could maybe even justify this as Critical. The error
message must reflect the correct quantity of addresses required.


On Tue, Nov 17, 2015 at 1:31 PM Roman Prykhodchenko  wrote:

> Folks, we should resurrect this thread and find a consensus.
>
> 1 вер. 2015 р. о 15:00 Andrey Danin  написав(ла):
>
>
> +1 to Igor.
>
> It's definitely not a High bug. The biggest problem I see here is a
> confusing error message with a wrong number of required IPs. AFAIU we
> cannot fix it easily now so let's postpone it to 8.0 but change a message
> itself [0] in 7.0.
>
> We managed to create an error that returns '7', when there are 8
available, but 9 are required, at some level we knew that we came up short
or we'd just have some lower level error caught here.

>
> [0]
> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/task/task.py#L1160-L1163
>
> On Tue, Sep 1, 2015 at 1:39 PM, Igor Kalnitsky 
> wrote:
>
>> Hello,
>>
>> My 5 cents on it.
>>
>> I don't think it's really a High or Critical bug for 7.0. If there's
>> not enough IPs the CheckBeforeDeploymentTask will fail. And that's
>> actually Ok, it may fail by different reason without starting actual
>> deployment (sending message to Astute).
>>
>> But I agree it's kinda strange that we don't check IPs during network
>> verification step. The good fix in my opinion is to move this check
>> into network checker (perhaps keep it here either), but that
>> definitely shouldn't be done in 7.0.
>>
>> Thanks,
>> Igor
>>
>>
>> On Mon, Aug 31, 2015 at 2:54 PM, Roman Prykhodchenko 
>> wrote:
>> > Hi folks!
>> >
>> > Recently a problem that network check does not tell whether there’s
>> enough IP addresses in a public network [1] was reported. That check is
>> performed by CheckBeforeDeployment task, but there is two problems that
>> happen because this verification is done that late:
>> >
>> >  - A deployment fails, if there’s not enough addresses in specified
>> ranges
>> >  - If a user wants to get network configuration they will get an error
>> >
>> > The solution for this problems seems to be easy and a straightforward
>> patch [2] was proposed. However, there is a hidden problem which is that
>> patch does not address which is that installed plugins may reserve VIPs for
>> their needs. The issue is that they do it just before deployment and so
>> it’s not possible to get those reservations when a user wants to check
>> their network set up.
>> >
>> > The important issue we have to address here is that network
>> configuration generator will fail, if specified ranges don’t fit all VIPs.
>> There were several proposals to fix that, I’d like to highlight two of them:
>> >
>> >  a) Allow VIPs to not have an IP address assigned, if network config
>> generator works for API output.
>> >  That will prevent GET requests from failure, but since IP
>> addresses for VIPs are required, generator will have to fail, if it
>> generates a configuration for the orchestrator.
>> >  b) Add a release note that users have to calculate IP addresses
>> manually and put sane ranges in order to not shoot their own legs. Then
>> it’s also possible to change network verification output to remind users to
>> check the ranges before starting a deployment.
>> >
>> > In my opinion we cannot follow (a) because it only masks a problem
>> instead of providing a fix. Also it requires to change the API which is not
>> a good thing to do after the SCF. If we choose (b), then we can work on a
>> firm solution in 8.0 and fix the problem for real.
>> >
>> >
>> > P. S. We can still merge [2], because it checks, if IP ranges can at
>> least fit the basic configuration. If you agree, I will update it soon.
>> >
>> > [1] https://bugs.launchpad.net/fuel/+bug/1487996
>> > [2] https://review.openstack.org/#/c/217267/
>> >
>> >
>> >
>> > - 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
>>
>
>
>
> --
> Andrey Danin
> ada...@mirantis.com
> skype: gcon.monolake
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

[Roman Prykhodchenko]

Folks, we should resurrect this thread and find a consensus.

> 1 вер. 2015 р. о 15:00 Andrey Danin  написав(ла):
> 
> +1 to Igor.
> 
> It's definitely not a High bug. The biggest problem I see here is a confusing 
> error message with a wrong number of required IPs. AFAIU we cannot fix it 
> easily now so let's postpone it to 8.0 but change a message itself [0] in 7.0.
> 
> [0] 
> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/task/task.py#L1160-L1163
>  
> 
> 
> On Tue, Sep 1, 2015 at 1:39 PM, Igor Kalnitsky  > wrote:
> Hello,
> 
> My 5 cents on it.
> 
> I don't think it's really a High or Critical bug for 7.0. If there's
> not enough IPs the CheckBeforeDeploymentTask will fail. And that's
> actually Ok, it may fail by different reason without starting actual
> deployment (sending message to Astute).
> 
> But I agree it's kinda strange that we don't check IPs during network
> verification step. The good fix in my opinion is to move this check
> into network checker (perhaps keep it here either), but that
> definitely shouldn't be done in 7.0.
> 
> Thanks,
> Igor
> 
> 
> On Mon, Aug 31, 2015 at 2:54 PM, Roman Prykhodchenko  > wrote:
> > Hi folks!
> >
> > Recently a problem that network check does not tell whether there’s enough 
> > IP addresses in a public network [1] was reported. That check is performed 
> > by CheckBeforeDeployment task, but there is two problems that happen 
> > because this verification is done that late:
> >
> >  - A deployment fails, if there’s not enough addresses in specified ranges
> >  - If a user wants to get network configuration they will get an error
> >
> > The solution for this problems seems to be easy and a straightforward patch 
> > [2] was proposed. However, there is a hidden problem which is that patch 
> > does not address which is that installed plugins may reserve VIPs for their 
> > needs. The issue is that they do it just before deployment and so it’s not 
> > possible to get those reservations when a user wants to check their network 
> > set up.
> >
> > The important issue we have to address here is that network configuration 
> > generator will fail, if specified ranges don’t fit all VIPs. There were 
> > several proposals to fix that, I’d like to highlight two of them:
> >
> >  a) Allow VIPs to not have an IP address assigned, if network config 
> > generator works for API output.
> >  That will prevent GET requests from failure, but since IP addresses 
> > for VIPs are required, generator will have to fail, if it generates a 
> > configuration for the orchestrator.
> >  b) Add a release note that users have to calculate IP addresses manually 
> > and put sane ranges in order to not shoot their own legs. Then it’s also 
> > possible to change network verification output to remind users to check the 
> > ranges before starting a deployment.
> >
> > In my opinion we cannot follow (a) because it only masks a problem instead 
> > of providing a fix. Also it requires to change the API which is not a good 
> > thing to do after the SCF. If we choose (b), then we can work on a firm 
> > solution in 8.0 and fix the problem for real.
> >
> >
> > P. S. We can still merge [2], because it checks, if IP ranges can at least 
> > fit the basic configuration. If you agree, I will update it soon.
> >
> > [1] https://bugs.launchpad.net/fuel/+bug/1487996 
> > 
> > [2] https://review.openstack.org/#/c/217267/ 
> > 
> >
> >
> >
> > - 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 
> 
> 
> 
> 
> --
> Andrey Danin
> ada...@mirantis.com 
> skype: gcon.monolake
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

[Igor Kalnitsky]

Hello,

My 5 cents on it.

I don't think it's really a High or Critical bug for 7.0. If there's
not enough IPs the CheckBeforeDeploymentTask will fail. And that's
actually Ok, it may fail by different reason without starting actual
deployment (sending message to Astute).

But I agree it's kinda strange that we don't check IPs during network
verification step. The good fix in my opinion is to move this check
into network checker (perhaps keep it here either), but that
definitely shouldn't be done in 7.0.

Thanks,
Igor


On Mon, Aug 31, 2015 at 2:54 PM, Roman Prykhodchenko  wrote:
> Hi folks!
>
> Recently a problem that network check does not tell whether there’s enough IP 
> addresses in a public network [1] was reported. That check is performed by 
> CheckBeforeDeployment task, but there is two problems that happen because 
> this verification is done that late:
>
>  - A deployment fails, if there’s not enough addresses in specified ranges
>  - If a user wants to get network configuration they will get an error
>
> The solution for this problems seems to be easy and a straightforward patch 
> [2] was proposed. However, there is a hidden problem which is that patch does 
> not address which is that installed plugins may reserve VIPs for their needs. 
> The issue is that they do it just before deployment and so it’s not possible 
> to get those reservations when a user wants to check their network set up.
>
> The important issue we have to address here is that network configuration 
> generator will fail, if specified ranges don’t fit all VIPs. There were 
> several proposals to fix that, I’d like to highlight two of them:
>
>  a) Allow VIPs to not have an IP address assigned, if network config 
> generator works for API output.
>  That will prevent GET requests from failure, but since IP addresses for 
> VIPs are required, generator will have to fail, if it generates a 
> configuration for the orchestrator.
>  b) Add a release note that users have to calculate IP addresses manually and 
> put sane ranges in order to not shoot their own legs. Then it’s also possible 
> to change network verification output to remind users to check the ranges 
> before starting a deployment.
>
> In my opinion we cannot follow (a) because it only masks a problem instead of 
> providing a fix. Also it requires to change the API which is not a good thing 
> to do after the SCF. If we choose (b), then we can work on a firm solution in 
> 8.0 and fix the problem for real.
>
>
> P. S. We can still merge [2], because it checks, if IP ranges can at least 
> fit the basic configuration. If you agree, I will update it soon.
>
> [1] https://bugs.launchpad.net/fuel/+bug/1487996
> [2] https://review.openstack.org/#/c/217267/
>
>
>
> - 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

Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

[Andrey Danin]

+1 to Igor.

It's definitely not a High bug. The biggest problem I see here is a
confusing error message with a wrong number of required IPs. AFAIU we
cannot fix it easily now so let's postpone it to 8.0 but change a message
itself [0] in 7.0.

[0]
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/task/task.py#L1160-L1163

On Tue, Sep 1, 2015 at 1:39 PM, Igor Kalnitsky 
wrote:

> Hello,
>
> My 5 cents on it.
>
> I don't think it's really a High or Critical bug for 7.0. If there's
> not enough IPs the CheckBeforeDeploymentTask will fail. And that's
> actually Ok, it may fail by different reason without starting actual
> deployment (sending message to Astute).
>
> But I agree it's kinda strange that we don't check IPs during network
> verification step. The good fix in my opinion is to move this check
> into network checker (perhaps keep it here either), but that
> definitely shouldn't be done in 7.0.
>
> Thanks,
> Igor
>
>
> On Mon, Aug 31, 2015 at 2:54 PM, Roman Prykhodchenko 
> wrote:
> > Hi folks!
> >
> > Recently a problem that network check does not tell whether there’s
> enough IP addresses in a public network [1] was reported. That check is
> performed by CheckBeforeDeployment task, but there is two problems that
> happen because this verification is done that late:
> >
> >  - A deployment fails, if there’s not enough addresses in specified
> ranges
> >  - If a user wants to get network configuration they will get an error
> >
> > The solution for this problems seems to be easy and a straightforward
> patch [2] was proposed. However, there is a hidden problem which is that
> patch does not address which is that installed plugins may reserve VIPs for
> their needs. The issue is that they do it just before deployment and so
> it’s not possible to get those reservations when a user wants to check
> their network set up.
> >
> > The important issue we have to address here is that network
> configuration generator will fail, if specified ranges don’t fit all VIPs.
> There were several proposals to fix that, I’d like to highlight two of them:
> >
> >  a) Allow VIPs to not have an IP address assigned, if network config
> generator works for API output.
> >  That will prevent GET requests from failure, but since IP addresses
> for VIPs are required, generator will have to fail, if it generates a
> configuration for the orchestrator.
> >  b) Add a release note that users have to calculate IP addresses
> manually and put sane ranges in order to not shoot their own legs. Then
> it’s also possible to change network verification output to remind users to
> check the ranges before starting a deployment.
> >
> > In my opinion we cannot follow (a) because it only masks a problem
> instead of providing a fix. Also it requires to change the API which is not
> a good thing to do after the SCF. If we choose (b), then we can work on a
> firm solution in 8.0 and fix the problem for real.
> >
> >
> > P. S. We can still merge [2], because it checks, if IP ranges can at
> least fit the basic configuration. If you agree, I will update it soon.
> >
> > [1] https://bugs.launchpad.net/fuel/+bug/1487996
> > [2] https://review.openstack.org/#/c/217267/
> >
> >
> >
> > - 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
>



-- 
Andrey Danin
ada...@mirantis.com
skype: gcon.monolake
__
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-dev] [Fuel] Number of IP addresses in a public network

[Roman Prykhodchenko]

Hi folks!

Recently a problem that network check does not tell whether there’s enough IP 
addresses in a public network [1] was reported. That check is performed by 
CheckBeforeDeployment task, but there is two problems that happen because this 
verification is done that late:

 - A deployment fails, if there’s not enough addresses in specified ranges
 - If a user wants to get network configuration they will get an error

The solution for this problems seems to be easy and a straightforward patch [2] 
was proposed. However, there is a hidden problem which is that patch does not 
address which is that installed plugins may reserve VIPs for their needs. The 
issue is that they do it just before deployment and so it’s not possible to get 
those reservations when a user wants to check their network set up.

The important issue we have to address here is that network configuration 
generator will fail, if specified ranges don’t fit all VIPs. There were several 
proposals to fix that, I’d like to highlight two of them:

 a) Allow VIPs to not have an IP address assigned, if network config generator 
works for API output.
 That will prevent GET requests from failure, but since IP addresses for 
VIPs are required, generator will have to fail, if it generates a configuration 
for the orchestrator.
 b) Add a release note that users have to calculate IP addresses manually and 
put sane ranges in order to not shoot their own legs. Then it’s also possible 
to change network verification output to remind users to check the ranges 
before starting a deployment.

In my opinion we cannot follow (a) because it only masks a problem instead of 
providing a fix. Also it requires to change the API which is not a good thing 
to do after the SCF. If we choose (b), then we can work on a firm solution in 
8.0 and fix the problem for real.


P. S. We can still merge [2], because it checks, if IP ranges can at least fit 
the basic configuration. If you agree, I will update it soon.

[1] https://bugs.launchpad.net/fuel/+bug/1487996
[2] https://review.openstack.org/#/c/217267/



- romcheg





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