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

[Igor Kalnitsky]

Hi all,

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 API call (currently we do it only in
before deployment checks).
3/ We should keep in mind (and perhaps make some ticket) about ability
to allocate VIPs on demand.. on some API call, or even be able to
assign custom one.

I think we need update LP ticket of (1), and file a ticket for (2).

Sounds like a plan, ha?

Thanks,
Igor

On Wed, Oct 21, 2015 at 3:54 PM, Aleksey Kasatkin
 wrote:
>> Then we should close [1] 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
> before deployment.
> I'm not sure what are the cases.
>
>
>
> Aleksey Kasatkin
>
>
> On Wed, Oct 21, 2015 at 11:45 AM, Roman Prykhodchenko  wrote:
>>
>> Then we should close [1] as invalid, shoudn’t we?
>>
>> > 20 жовт. 2015 р. о 15:55 Igor Kalnitsky 
>> > написав(ла):
>> >
>> > Roman,
>> >
>> >> This behavior is actually described in [1]. 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.
>> >
>> > - igor
>> >
>> > On Tue, Oct 20, 2015 at 4:54 PM, Igor Kalnitsky
>> >  wrote:
>> >> Andrew,
>> >>
>> >>> 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
>> >> role itself has nothing in common with VIPs. It doesn't require any of
>> >> them.
>> >>
>> >> Currently VIPs are requested by network roles, and network roles are
>> >> the same for all nodes (except Network Templating case). Network roles
>> >> are assigned on network, and if VIP is required for network role it
>> >> will be allocated in the assigned network.
>> >>
>> >> So basically, it requires a huge effort to redesign our allocation
>> >> system to achieve what you want, because:
>> >>
>> >> * Each time you reassign network role, the corresponding VIP should be
>> >> re-allocated in the database either.
>> >> * Each time you enable/disable plugins, the VIPs should be
>> >> re-allocated, because plugins may export network roles.
>> >> * Each time you add new node to cluster, the VIPs should be
>> >> re-allocated, because with new node you simply may run out of free
>> >> IPs. And, btw, should we assign IP on added nodes here? Or maybe
>> >> postpone to serialization step?
>> >>
>> >> Well, Andrew, I believe we don't have enough resources to implement
>> >> your proposal. Moreover, the proposed approach requires a lot of
>> >> discussions and design meetings. And it definitely should be
>> >> implemented in scope of some blueprint, not a bugfix.
>> >>
>> >>
>> >>> Not knowing the address until serialization for deployment is too
>> >>> late.
>> >>
>> >> Once again - why? I agree, perhaps it would be useful, but there's no
>> >> strict requirement on this and we should resolve our issues
>> >> step-by-step. See my response above.
>> >>
>> >>
>> >>> No, Again, this is too late.
>> >>
>> >> Too late for what?
>> >>
>> >>
>> >> - Igor
>> >>
>> >> On Tue, Oct 20, 2015 at 12:38 PM, Roman Prykhodchenko 
>> >> wrote:
>> >>> 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 
>>  написав(ла):
>> 
>>  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 

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

[Aleksey Kasatkin]

> Then we should close [1] 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
before deployment.
I'm not sure what are the cases.



Aleksey Kasatkin


On Wed, Oct 21, 2015 at 11:45 AM, Roman Prykhodchenko  wrote:

> Then we should close [1] as invalid, shoudn’t we?
>
> > 20 жовт. 2015 р. о 15:55 Igor Kalnitsky 
> написав(ла):
> >
> > Roman,
> >
> >> This behavior is actually described in [1]. 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.
> >
> > - igor
> >
> > On Tue, Oct 20, 2015 at 4:54 PM, Igor Kalnitsky 
> wrote:
> >> Andrew,
> >>
> >>> 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
> >> role itself has nothing in common with VIPs. It doesn't require any of
> >> them.
> >>
> >> Currently VIPs are requested by network roles, and network roles are
> >> the same for all nodes (except Network Templating case). Network roles
> >> are assigned on network, and if VIP is required for network role it
> >> will be allocated in the assigned network.
> >>
> >> So basically, it requires a huge effort to redesign our allocation
> >> system to achieve what you want, because:
> >>
> >> * Each time you reassign network role, the corresponding VIP should be
> >> re-allocated in the database either.
> >> * Each time you enable/disable plugins, the VIPs should be
> >> re-allocated, because plugins may export network roles.
> >> * Each time you add new node to cluster, the VIPs should be
> >> re-allocated, because with new node you simply may run out of free
> >> IPs. And, btw, should we assign IP on added nodes here? Or maybe
> >> postpone to serialization step?
> >>
> >> Well, Andrew, I believe we don't have enough resources to implement
> >> your proposal. Moreover, the proposed approach requires a lot of
> >> discussions and design meetings. And it definitely should be
> >> implemented in scope of some blueprint, not a bugfix.
> >>
> >>
> >>> Not knowing the address until serialization for deployment is too late.
> >>
> >> Once again - why? I agree, perhaps it would be useful, but there's no
> >> strict requirement on this and we should resolve our issues
> >> step-by-step. See my response above.
> >>
> >>
> >>> No, Again, this is too late.
> >>
> >> Too late for what?
> >>
> >>
> >> - Igor
> >>
> >> On Tue, Oct 20, 2015 at 12:38 PM, Roman Prykhodchenko 
> wrote:
> >>> 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 
> написав(ла):
> 
>  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 

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

[Roman Prykhodchenko]

Then we should close [1] as invalid, shoudn’t we?

> 20 жовт. 2015 р. о 15:55 Igor Kalnitsky  написав(ла):
> 
> Roman,
> 
>> This behavior is actually described in [1]. 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.
> 
> - igor
> 
> On Tue, Oct 20, 2015 at 4:54 PM, Igor Kalnitsky  
> wrote:
>> Andrew,
>> 
>>> 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
>> role itself has nothing in common with VIPs. It doesn't require any of
>> them.
>> 
>> Currently VIPs are requested by network roles, and network roles are
>> the same for all nodes (except Network Templating case). Network roles
>> are assigned on network, and if VIP is required for network role it
>> will be allocated in the assigned network.
>> 
>> So basically, it requires a huge effort to redesign our allocation
>> system to achieve what you want, because:
>> 
>> * Each time you reassign network role, the corresponding VIP should be
>> re-allocated in the database either.
>> * Each time you enable/disable plugins, the VIPs should be
>> re-allocated, because plugins may export network roles.
>> * Each time you add new node to cluster, the VIPs should be
>> re-allocated, because with new node you simply may run out of free
>> IPs. And, btw, should we assign IP on added nodes here? Or maybe
>> postpone to serialization step?
>> 
>> Well, Andrew, I believe we don't have enough resources to implement
>> your proposal. Moreover, the proposed approach requires a lot of
>> discussions and design meetings. And it definitely should be
>> implemented in scope of some blueprint, not a bugfix.
>> 
>> 
>>> Not knowing the address until serialization for deployment is too late.
>> 
>> Once again - why? I agree, perhaps it would be useful, but there's no
>> strict requirement on this and we should resolve our issues
>> step-by-step. See my response above.
>> 
>> 
>>> No, Again, this is too late.
>> 
>> Too late for what?
>> 
>> 
>> - Igor
>> 
>> On Tue, Oct 20, 2015 at 12:38 PM, Roman Prykhodchenko  
>> wrote:
>>> 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  
 написав(ла):
 
 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  
 wrote:
> Hi folks!
> 
> I’ve 

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

[Roman Prykhodchenko]

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  написав(ла):
> 
> 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  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

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

[Igor Kalnitsky]

Andrew,

> 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
role itself has nothing in common with VIPs. It doesn't require any of
them.

Currently VIPs are requested by network roles, and network roles are
the same for all nodes (except Network Templating case). Network roles
are assigned on network, and if VIP is required for network role it
will be allocated in the assigned network.

So basically, it requires a huge effort to redesign our allocation
system to achieve what you want, because:

* Each time you reassign network role, the corresponding VIP should be
re-allocated in the database either.
* Each time you enable/disable plugins, the VIPs should be
re-allocated, because plugins may export network roles.
* Each time you add new node to cluster, the VIPs should be
re-allocated, because with new node you simply may run out of free
IPs. And, btw, should we assign IP on added nodes here? Or maybe
postpone to serialization step?

Well, Andrew, I believe we don't have enough resources to implement
your proposal. Moreover, the proposed approach requires a lot of
discussions and design meetings. And it definitely should be
implemented in scope of some blueprint, not a bugfix.


> Not knowing the address until serialization for deployment is too late.

Once again - why? I agree, perhaps it would be useful, but there's no
strict requirement on this and we should resolve our issues
step-by-step. See my response above.


> No, Again, this is too late.

Too late for what?


- Igor

On Tue, Oct 20, 2015 at 12:38 PM, Roman Prykhodchenko  wrote:
> 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  
>> написав(ла):
>>
>> 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  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 

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

[Igor Kalnitsky]

Roman,

> This behavior is actually described in [1]. 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.

- igor

On Tue, Oct 20, 2015 at 4:54 PM, Igor Kalnitsky  wrote:
> Andrew,
>
>> 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
> role itself has nothing in common with VIPs. It doesn't require any of
> them.
>
> Currently VIPs are requested by network roles, and network roles are
> the same for all nodes (except Network Templating case). Network roles
> are assigned on network, and if VIP is required for network role it
> will be allocated in the assigned network.
>
> So basically, it requires a huge effort to redesign our allocation
> system to achieve what you want, because:
>
> * Each time you reassign network role, the corresponding VIP should be
> re-allocated in the database either.
> * Each time you enable/disable plugins, the VIPs should be
> re-allocated, because plugins may export network roles.
> * Each time you add new node to cluster, the VIPs should be
> re-allocated, because with new node you simply may run out of free
> IPs. And, btw, should we assign IP on added nodes here? Or maybe
> postpone to serialization step?
>
> Well, Andrew, I believe we don't have enough resources to implement
> your proposal. Moreover, the proposed approach requires a lot of
> discussions and design meetings. And it definitely should be
> implemented in scope of some blueprint, not a bugfix.
>
>
>> Not knowing the address until serialization for deployment is too late.
>
> Once again - why? I agree, perhaps it would be useful, but there's no
> strict requirement on this and we should resolve our issues
> step-by-step. See my response above.
>
>
>> No, Again, this is too late.
>
> Too late for what?
>
>
> - Igor
>
> On Tue, Oct 20, 2015 at 12:38 PM, Roman Prykhodchenko  wrote:
>> 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  
>>> написав(ла):
>>>
>>> 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  
>>> 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 
 

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

[Andrew Woodward]

On Mon, Oct 19, 2015 at 9:29 AM Igor Kalnitsky 
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 
> 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)
> 

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

[Aleksey Kasatkin]

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 
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 
> 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
>
__
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] Assigning VIPs on network config serialization

[Igor Kalnitsky]

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
 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 
> 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 
>> 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
>> >
>>
>> 

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

[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 *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  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

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

[Roman Prykhodchenko]

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


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