Re: [openstack-dev] [neutron] - availability zone performance regression and discussion about added network field

[Hirofumi Ichihara]

On 2015/12/16 17:16, Kevin Benton wrote:
What will the availability zones API tell the user about the zones? 
Are they just opaque strings that the user doesn't really understand?

They shows available zones in the time.



What I'm a little worried about is that it seems like we are having 
the user doing the work of the scheduler.
I understand your worry. However, I think that AZ feature includes a use 
case that users can specify zone which their resource is scheduled.




Is this is for getting affinity or anti-affinity with resources for 
another network? If so, why not just have the user explicitly say in 
the API request 'anti-affinity=network_id' or 'affinity=network_id'. 
Then the scheduler would use the zones info to either place resources 
on a different zone or the same zone, depending on which was requested.



I like it. But we may have other issues, for example,

1. We have NW1(with anti-affinity=NW2) and NW2(with anti-affinity=NW1)
2. We delete NW1 and then create NW3(with anti-affinity=NW2) instead of NW1
3. NW2(with anti-affinity=NW1) is rescheduled because of some reasons
4. Neutron cannot find NW1 in anti-affinit of NW2. How does neutron also 
schedule NW2 to a zone which doesn't have NW3?


Of course, we can find a way of solving this issue itself. But the 
similar issue may happen.


I think that we must remove the filed if it always happens performance 
issue.
However, we should find out another solution for the issue as long as 
there are use cases that are needed by operators and users.


On Sun, Dec 13, 2015 at 11:25 PM, Hirofumi Ichihara 
> wrote:




On 2015/12/14 15:58, Kevin Benton wrote:

What decision would lead the user to request AZ1 and AZ2 in the
first place? Especially since when it fails to get AZ2, they just
request again with AZ1 and AZ3 instead.

I expected that user gets AZ1 and AZ2 (and AZ3) via GET
Availability zones API first. There is a gap between the time user
threw and the time his resource is scheduled. After user threw API
request with AZ1 and AZ2, if all agents of AZ2 are dead before
scheduling, the resource is scheduled in AZ1 only.





On Sun, Dec 13, 2015 at 10:31 PM, Hirofumi Ichihara
> wrote:



On 2015/12/14 14:52, Kevin Benton wrote:

I see, so regular users are supposed to use this information
as well. But how are they supposed to use it? For example,
if they see that their network has availability zones 1 and
4, but their instance is hosted in zone 3, what are they
supposed to do?

I don't think that there is what they should do in the case
because Neutron AZ is different from Nova AZ. For example,
there may be a case like the following.

1. User throws POST Network API and Subnet API with
availability_zone_hints [AZ1, AZ2]
2. Neutron server tries to schedule the resource on both AZ1
and AZ2 but the resource are scheduled on AZ1 only by some
reasons
3. User confirms via GET Network API where his resource is
hosted and he knows it's AZ1 only
4. User also can know AZ is ready via GET Availability zones
API: AZ1, AZ3
5. User deletes previous resource and he recreates his
resource with availability_zone_hints [AZ1, AZ3]




On Sun, Dec 13, 2015 at 8:57 PM, Hirofumi Ichihara
> wrote:

Hi Kevin,

On 2015/12/14 11:10, Kevin Benton wrote:

Hi all,

The availability zone code added a new field to the
network API that shows the availability zones of a
network. This caused a pretty big performance impact to
get_networks calls because it resulted in a database
lookup for every network.[1]

I already put a patch up to join the information ahead
of time in the network model.[2]

I agree with your suggestion. I believe that the patch
can solve the performance issue.


However, before we go forward with that, I think we
should consider the removal of that field from the API.

Having to always join to the DHCP agents table to
lookup which zones a network has DHCP agents on is
expensive and is duplicating information available with
other API calls.

Additionally, the field is just called
'availability_zones' but it's being derived solely from
AZ definitions in DHCP agent bindings for that network.
To me that doesn't represent where the network is
available, it just says which zones its scheduled DHCP
instances live in. If that's the 

Re: [openstack-dev] [neutron] - availability zone performance regression and discussion about added network field

[Kevin Benton]

What will the availability zones API tell the user about the zones? Are
they just opaque strings that the user doesn't really understand?

What I'm a little worried about is that it seems like we are having the
user doing the work of the scheduler.

Is this is for getting affinity or anti-affinity with resources for another
network? If so, why not just have the user explicitly say in the API
request 'anti-affinity=network_id' or 'affinity=network_id'. Then the
scheduler would use the zones info to either place resources on a different
zone or the same zone, depending on which was requested.

On Sun, Dec 13, 2015 at 11:25 PM, Hirofumi Ichihara <
ichihara.hirof...@lab.ntt.co.jp> wrote:

>
>
> On 2015/12/14 15:58, Kevin Benton wrote:
>
> What decision would lead the user to request AZ1 and AZ2 in the first
> place? Especially since when it fails to get AZ2, they just request again
> with AZ1 and AZ3 instead.
>
> I expected that user gets AZ1 and AZ2 (and AZ3) via GET Availability zones
> API first. There is a gap between the time user threw and the time his
> resource is scheduled. After user threw API request with AZ1 and AZ2, if
> all agents of AZ2 are dead before scheduling, the resource is scheduled in
> AZ1 only.
>
>
>
>
> On Sun, Dec 13, 2015 at 10:31 PM, Hirofumi Ichihara <
> ichihara.hirof...@lab.ntt.co.jp> wrote:
>
>>
>>
>> On 2015/12/14 14:52, Kevin Benton wrote:
>>
>> I see, so regular users are supposed to use this information as well. But
>> how are they supposed to use it? For example, if they see that their
>> network has availability zones 1 and 4, but their instance is hosted in
>> zone 3, what are they supposed to do?
>>
>> I don't think that there is what they should do in the case because
>> Neutron AZ is different from Nova AZ. For example, there may be a case like
>> the following.
>>
>> 1. User throws POST Network API and Subnet API with
>> availability_zone_hints [AZ1, AZ2]
>> 2. Neutron server tries to schedule the resource on both AZ1 and AZ2 but
>> the resource are scheduled on AZ1 only by some reasons
>> 3. User confirms via GET Network API where his resource is hosted and he
>> knows it's AZ1 only
>> 4. User also can know AZ is ready via GET Availability zones API: AZ1, AZ3
>> 5. User deletes previous resource and he recreates his resource with
>> availability_zone_hints [AZ1, AZ3]
>>
>>
>>
>> On Sun, Dec 13, 2015 at 8:57 PM, Hirofumi Ichihara <
>> ichihara.hirof...@lab.ntt.co.jp> wrote:
>>
>>> Hi Kevin,
>>>
>>> On 2015/12/14 11:10, Kevin Benton wrote:
>>>
>>> Hi all,
>>>
>>> The availability zone code added a new field to the network API that
>>> shows the availability zones of a network. This caused a pretty big
>>> performance impact to get_networks calls because it resulted in a database
>>> lookup for every network.[1]
>>>
>>> I already put a patch up to join the information ahead of time in the
>>> network model.[2]
>>>
>>> I agree with your suggestion. I believe that the patch can solve the
>>> performance issue.
>>>
>>> However, before we go forward with that, I think we should consider the
>>> removal of that field from the API.
>>>
>>> Having to always join to the DHCP agents table to lookup which zones a
>>> network has DHCP agents on is expensive and is duplicating information
>>> available with other API calls.
>>>
>>> Additionally, the field is just called 'availability_zones' but it's
>>> being derived solely from AZ definitions in DHCP agent bindings for that
>>> network. To me that doesn't represent where the network is available, it
>>> just says which zones its scheduled DHCP instances live in. If that's the
>>> purpose, then we should just be using the DHCP agent API for this info and
>>> not impact the network API.
>>>
>>> I don't think so. I have three points.
>>>
>>> 1. Availability zone is implemented in just a case with Agent now, but
>>> it's reference implementation. For example, we should expect that
>>> availability zone will be used by plugin without agent.
>>>
>>> 2. In users view, availability zone is related to network resource. On
>>> the other hand, users doesn't need to consider Agent or operators doesn't
>>> like to enable users to do in the first place. So I don't agree with using
>>> Agent API.
>>>
>>> 3. We should consider whether users want to know the field. Originally,
>>> the field doesn't exist in Spec[3] but I added it according with reviewer's
>>> opinion(maybe Akihiro?). This is about discussion of use case. After users
>>> create resources via API with availability_zone_hints so that they achieve
>>> HA for their service, they want to know which zones are their resources
>>> hosted on because their resources might not be distributed on multiple
>>> availability zones by any reasons. In the case, they need to know
>>> "availability_zones" for the resources via Network API.
>>>
>>> Thanks,
>>> Hirofumi
>>>
>>> [3]: https://review.openstack.org/#/c/169612/31
>>>
>>>
>>> 

Re: [openstack-dev] [neutron] - availability zone performance regression and discussion about added network field

[Armando M.]

On 13 December 2015 at 23:01, Kevin Benton <blak...@gmail.com> wrote:

> Yes, as I'm starting to understand the use case, I think it would actually
> make more sense to add an AZ-network mapping table. Then whatever
> implementation can populate them based on the criteria it is using
> (reference would just do it on agent updates).
>

I guess this would be leading to have AZ being first class (ie. being in a
table of its own) and associate it 1-N to agents and N-M to networks. It
might not be worth going down this path for killing the performance penalty
introduced by this feature, though it might be worth considering the model
change to accommodate other features where we could extend the grouping to
other resources like L2.


>
> On Sun, Dec 13, 2015 at 9:53 PM, Hong Hui Xiao <xiaoh...@cn.ibm.com>
> wrote:
>
>> Hi,
>>
>> Can we just add "availability_zones" as one Column in Network? And
>> update it when "NetworkDhcpAgentBinding" updates. The code will be a bit
>> more complex, but it can save the time when retrieving Network resource.
>>
>>
>>
>> [image: Inactive hide details for Hirofumi Ichihara ---12/14/2015
>> 13:33:41---Hi Kevin, On 2015/12/14 11:10, Kevin Benton wrote:]Hirofumi
>> Ichihara ---12/14/2015 13:33:41---Hi Kevin, On 2015/12/14 11:10, Kevin
>> Benton wrote:
>>
>> From: Hirofumi Ichihara <ichihara.hirof...@lab.ntt.co.jp>
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Date: 12/14/2015 13:33
>> Subject: Re: [openstack-dev] [neutron] - availability zone performance
>> regression and discussion about added network field
>> --
>>
>>
>>
>> Hi Kevin,
>>
>> On 2015/12/14 11:10, Kevin Benton wrote:
>>
>>Hi all,
>>
>>   The availability zone code added a new field to the network API
>>   that shows the availability zones of a network. This caused a pretty 
>> big
>>   performance impact to get_networks calls because it resulted in a 
>> database
>>   lookup for every network.[1]
>>
>>   I already put a patch up to join the information ahead of time in
>>   the network model.[2]
>>
>> I agree with your suggestion. I believe that the patch can solve the
>> performance issue.
>>
>>However, before we go forward with that, I think we should consider
>>   the removal of that field from the API.
>>
>>   Having to always join to the DHCP agents table to lookup which
>>   zones a network has DHCP agents on is expensive and is duplicating
>>   information available with other API calls.
>>
>>   Additionally, the field is just called 'availability_zones' but
>>   it's being derived solely from AZ definitions in DHCP agent bindings 
>> for
>>   that network. To me that doesn't represent where the network is 
>> available,
>>   it just says which zones its scheduled DHCP instances live in. If 
>> that's
>>   the purpose, then we should just be using the DHCP agent API for this 
>> info
>>   and not impact the network API.
>>
>> I don't think so. I have three points.
>>
>> 1. Availability zone is implemented in just a case with Agent now, but
>> it's reference implementation. For example, we should expect that
>> availability zone will be used by plugin without agent.
>>
>> 2. In users view, availability zone is related to network resource. On
>> the other hand, users doesn't need to consider Agent or operators doesn't
>> like to enable users to do in the first place. So I don't agree with using
>> Agent API.
>>
>> 3. We should consider whether users want to know the field. Originally,
>> the field doesn't exist in Spec[3] but I added it according with reviewer's
>> opinion(maybe Akihiro?). This is about discussion of use case. After users
>> create resources via API with availability_zone_hints so that they achieve
>> HA for their service, they want to know which zones are their resources
>> hosted on because their resources might not be distributed on multiple
>> availability zones by any reasons. In the case, they need to know
>> "availability_zones" for the resources via Network API.
>>
>> Thanks,
>> Hirofumi
>>
>> [3]: *https://review.openstack.org/#/c/169612/31*
>> <https://review.openstack.org/#/c/169612/31>
>>
>>
>>   Thoughts?
>>
>>   1. *https://bugs.launchpad.net/neutron/+bug/1525740*
>>   <

Re: [openstack-dev] [neutron] - availability zone performance regression and discussion about added network field

[Hirofumi Ichihara]

Hi Kevin,

On 2015/12/14 11:10, Kevin Benton wrote:

Hi all,

The availability zone code added a new field to the network API that 
shows the availability zones of a network. This caused a pretty big 
performance impact to get_networks calls because it resulted in a 
database lookup for every network.[1]


I already put a patch up to join the information ahead of time in the 
network model.[2]
I agree with your suggestion. I believe that the patch can solve the 
performance issue.


However, before we go forward with that, I think we should consider 
the removal of that field from the API.


Having to always join to the DHCP agents table to lookup which zones a 
network has DHCP agents on is expensive and is duplicating information 
available with other API calls.


Additionally, the field is just called 'availability_zones' but it's 
being derived solely from AZ definitions in DHCP agent bindings for 
that network. To me that doesn't represent where the network is 
available, it just says which zones its scheduled DHCP instances live 
in. If that's the purpose, then we should just be using the DHCP agent 
API for this info and not impact the network API.

I don't think so. I have three points.

1. Availability zone is implemented in just a case with Agent now, but 
it's reference implementation. For example, we should expect that 
availability zone will be used by plugin without agent.


2. In users view, availability zone is related to network resource. On 
the other hand, users doesn't need to consider Agent or operators 
doesn't like to enable users to do in the first place. So I don't agree 
with using Agent API.


3. We should consider whether users want to know the field. Originally, 
the field doesn't exist in Spec[3] but I added it according with 
reviewer's opinion(maybe Akihiro?). This is about discussion of use 
case. After users create resources via API with availability_zone_hints 
so that they achieve HA for their service, they want to know which zones 
are their resources hosted on because their resources might not be 
distributed on multiple availability zones by any reasons. In the case, 
they need to know "availability_zones" for the resources via Network API.


Thanks,
Hirofumi

[3]: https://review.openstack.org/#/c/169612/31



Thoughts?

1. https://bugs.launchpad.net/neutron/+bug/1525740
2. https://review.openstack.org/#/c/257086/

--
Kevin Benton


__
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] [neutron] - availability zone performance regression and discussion about added network field

[Hong Hui Xiao]

Hi,

Can we just add "availability_zones" as one Column in Network? And
update it when "NetworkDhcpAgentBinding" updates. The code will be a bit
more complex, but it can save the time when retrieving Network resource.





From:   Hirofumi Ichihara <ichihara.hirof...@lab.ntt.co.jp>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   12/14/2015 13:33
Subject:Re: [openstack-dev] [neutron] - availability zone performance
    regression and discussion about added network field



Hi Kevin,

On 2015/12/14 11:10, Kevin Benton wrote:
  Hi all,

  The availability zone code added a new field to the network API that
  shows the availability zones of a network. This caused a pretty big
  performance impact to get_networks calls because it resulted in a
  database lookup for every network.[1]

  I already put a patch up to join the information ahead of time in the
  network model.[2]
I agree with your suggestion. I believe that the patch can solve the
performance issue.

  However, before we go forward with that, I think we should consider
  the removal of that field from the API.

  Having to always join to the DHCP agents table to lookup which zones
  a network has DHCP agents on is expensive and is duplicating
  information available with other API calls.

  Additionally, the field is just called 'availability_zones' but it's
  being derived solely from AZ definitions in DHCP agent bindings for
  that network. To me that doesn't represent where the network is
  available, it just says which zones its scheduled DHCP instances live
  in. If that's the purpose, then we should just be using the DHCP
  agent API for this info and not impact the network API.
I don't think so. I have three points.

1. Availability zone is implemented in just a case with Agent now, but it's
reference implementation. For example, we should expect that availability
zone will be used by plugin without agent.

2. In users view, availability zone is related to network resource. On the
other hand, users doesn't need to consider Agent or operators doesn't like
to enable users to do in the first place. So I don't agree with using Agent
API.

3. We should consider whether users want to know the field. Originally, the
field doesn't exist in Spec[3] but I added it according with reviewer's
opinion(maybe Akihiro?). This is about discussion of use case. After users
create resources via API with availability_zone_hints so that they achieve
HA for their service, they want to know which zones are their resources
hosted on because their resources might not be distributed on multiple
availability zones by any reasons. In the case, they need to know
"availability_zones" for the resources via Network API.

Thanks,
Hirofumi

[3]: https://review.openstack.org/#/c/169612/31


  Thoughts?

  1. https://bugs.launchpad.net/neutron/+bug/1525740
  2. https://review.openstack.org/#/c/257086/

  --
  Kevin Benton


  __

  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] [neutron] - availability zone performance regression and discussion about added network field

[Kevin Benton]

I see, so regular users are supposed to use this information as well. But
how are they supposed to use it? For example, if they see that their
network has availability zones 1 and 4, but their instance is hosted in
zone 3, what are they supposed to do?

On Sun, Dec 13, 2015 at 8:57 PM, Hirofumi Ichihara <
ichihara.hirof...@lab.ntt.co.jp> wrote:

> Hi Kevin,
>
> On 2015/12/14 11:10, Kevin Benton wrote:
>
> Hi all,
>
> The availability zone code added a new field to the network API that shows
> the availability zones of a network. This caused a pretty big performance
> impact to get_networks calls because it resulted in a database lookup for
> every network.[1]
>
> I already put a patch up to join the information ahead of time in the
> network model.[2]
>
> I agree with your suggestion. I believe that the patch can solve the
> performance issue.
>
> However, before we go forward with that, I think we should consider the
> removal of that field from the API.
>
> Having to always join to the DHCP agents table to lookup which zones a
> network has DHCP agents on is expensive and is duplicating information
> available with other API calls.
>
> Additionally, the field is just called 'availability_zones' but it's being
> derived solely from AZ definitions in DHCP agent bindings for that network.
> To me that doesn't represent where the network is available, it just says
> which zones its scheduled DHCP instances live in. If that's the purpose,
> then we should just be using the DHCP agent API for this info and not
> impact the network API.
>
> I don't think so. I have three points.
>
> 1. Availability zone is implemented in just a case with Agent now, but
> it's reference implementation. For example, we should expect that
> availability zone will be used by plugin without agent.
>
> 2. In users view, availability zone is related to network resource. On the
> other hand, users doesn't need to consider Agent or operators doesn't like
> to enable users to do in the first place. So I don't agree with using Agent
> API.
>
> 3. We should consider whether users want to know the field. Originally,
> the field doesn't exist in Spec[3] but I added it according with reviewer's
> opinion(maybe Akihiro?). This is about discussion of use case. After users
> create resources via API with availability_zone_hints so that they achieve
> HA for their service, they want to know which zones are their resources
> hosted on because their resources might not be distributed on multiple
> availability zones by any reasons. In the case, they need to know
> "availability_zones" for the resources via Network API.
>
> Thanks,
> Hirofumi
>
> [3]: https://review.openstack.org/#/c/169612/31
>
>
> Thoughts?
>
> 1. https://bugs.launchpad.net/neutron/+bug/1525740
> 2. https://review.openstack.org/#/c/257086/
>
> --
> Kevin Benton
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>


-- 
Kevin Benton
__
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] [neutron] - availability zone performance regression and discussion about added network field

[Kevin Benton]

Hi all,

The availability zone code added a new field to the network API that shows
the availability zones of a network. This caused a pretty big performance
impact to get_networks calls because it resulted in a database lookup for
every network.[1]

I already put a patch up to join the information ahead of time in the
network model.[2] However, before we go forward with that, I think we
should consider the removal of that field from the API.

Having to always join to the DHCP agents table to lookup which zones a
network has DHCP agents on is expensive and is duplicating information
available with other API calls.

Additionally, the field is just called 'availability_zones' but it's being
derived solely from AZ definitions in DHCP agent bindings for that network.
To me that doesn't represent where the network is available, it just says
which zones its scheduled DHCP instances live in. If that's the purpose,
then we should just be using the DHCP agent API for this info and not
impact the network API.

Thoughts?

1. https://bugs.launchpad.net/neutron/+bug/1525740
2. https://review.openstack.org/#/c/257086/

-- 
Kevin Benton
__
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] [neutron] - availability zone performance regression and discussion about added network field

[Kevin Benton]

Yes, as I'm starting to understand the use case, I think it would actually
make more sense to add an AZ-network mapping table. Then whatever
implementation can populate them based on the criteria it is using
(reference would just do it on agent updates).

On Sun, Dec 13, 2015 at 9:53 PM, Hong Hui Xiao <xiaoh...@cn.ibm.com> wrote:

> Hi,
>
> Can we just add "availability_zones" as one Column in Network? And update
> it when "NetworkDhcpAgentBinding" updates. The code will be a bit more
> complex, but it can save the time when retrieving Network resource.
>
>
>
> [image: Inactive hide details for Hirofumi Ichihara ---12/14/2015
> 13:33:41---Hi Kevin, On 2015/12/14 11:10, Kevin Benton wrote:]Hirofumi
> Ichihara ---12/14/2015 13:33:41---Hi Kevin, On 2015/12/14 11:10, Kevin
> Benton wrote:
>
> From: Hirofumi Ichihara <ichihara.hirof...@lab.ntt.co.jp>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 12/14/2015 13:33
> Subject: Re: [openstack-dev] [neutron] - availability zone performance
> regression and discussion about added network field
> --
>
>
>
> Hi Kevin,
>
> On 2015/12/14 11:10, Kevin Benton wrote:
>
>Hi all,
>
>   The availability zone code added a new field to the network API
>   that shows the availability zones of a network. This caused a pretty big
>   performance impact to get_networks calls because it resulted in a 
> database
>   lookup for every network.[1]
>
>   I already put a patch up to join the information ahead of time in
>   the network model.[2]
>
> I agree with your suggestion. I believe that the patch can solve the
> performance issue.
>
>However, before we go forward with that, I think we should consider
>   the removal of that field from the API.
>
>   Having to always join to the DHCP agents table to lookup which
>   zones a network has DHCP agents on is expensive and is duplicating
>   information available with other API calls.
>
>   Additionally, the field is just called 'availability_zones' but
>   it's being derived solely from AZ definitions in DHCP agent bindings for
>   that network. To me that doesn't represent where the network is 
> available,
>   it just says which zones its scheduled DHCP instances live in. If that's
>   the purpose, then we should just be using the DHCP agent API for this 
> info
>   and not impact the network API.
>
> I don't think so. I have three points.
>
> 1. Availability zone is implemented in just a case with Agent now, but
> it's reference implementation. For example, we should expect that
> availability zone will be used by plugin without agent.
>
> 2. In users view, availability zone is related to network resource. On the
> other hand, users doesn't need to consider Agent or operators doesn't like
> to enable users to do in the first place. So I don't agree with using Agent
> API.
>
> 3. We should consider whether users want to know the field. Originally,
> the field doesn't exist in Spec[3] but I added it according with reviewer's
> opinion(maybe Akihiro?). This is about discussion of use case. After users
> create resources via API with availability_zone_hints so that they achieve
> HA for their service, they want to know which zones are their resources
> hosted on because their resources might not be distributed on multiple
> availability zones by any reasons. In the case, they need to know
> "availability_zones" for the resources via Network API.
>
> Thanks,
> Hirofumi
>
> [3]: *https://review.openstack.org/#/c/169612/31*
> <https://review.openstack.org/#/c/169612/31>
>
>
>   Thoughts?
>
>   1. *https://bugs.launchpad.net/neutron/+bug/1525740*
>   <https://bugs.launchpad.net/neutron/+bug/1525740>
>   2. *https://review.openstack.org/#/c/257086/*
>   <https://review.openstack.org/#/c/257086/>
>
>   --
>   Kevin Benton
>
>
>
>   
> __
>   OpenStack Development Mailing List (not for usage questions)
>   Unsubscribe:
>   *openstack-dev-requ...@lists.openstack.org?subject:unsubscribe*
>   <openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>   *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
>   <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubsc

Re: [openstack-dev] [neutron] - availability zone performance regression and discussion about added network field

[Hirofumi Ichihara]

On 2015/12/14 15:58, Kevin Benton wrote:
What decision would lead the user to request AZ1 and AZ2 in the first 
place? Especially since when it fails to get AZ2, they just request 
again with AZ1 and AZ3 instead.
I expected that user gets AZ1 and AZ2 (and AZ3) via GET Availability 
zones API first. There is a gap between the time user threw and the time 
his resource is scheduled. After user threw API request with AZ1 and 
AZ2, if all agents of AZ2 are dead before scheduling, the resource is 
scheduled in AZ1 only.





On Sun, Dec 13, 2015 at 10:31 PM, Hirofumi Ichihara 
> wrote:




On 2015/12/14 14:52, Kevin Benton wrote:

I see, so regular users are supposed to use this information as
well. But how are they supposed to use it? For example, if they
see that their network has availability zones 1 and 4, but their
instance is hosted in zone 3, what are they supposed to do?

I don't think that there is what they should do in the case
because Neutron AZ is different from Nova AZ. For example, there
may be a case like the following.

1. User throws POST Network API and Subnet API with
availability_zone_hints [AZ1, AZ2]
2. Neutron server tries to schedule the resource on both AZ1 and
AZ2 but the resource are scheduled on AZ1 only by some reasons
3. User confirms via GET Network API where his resource is hosted
and he knows it's AZ1 only
4. User also can know AZ is ready via GET Availability zones API:
AZ1, AZ3
5. User deletes previous resource and he recreates his resource
with availability_zone_hints [AZ1, AZ3]




On Sun, Dec 13, 2015 at 8:57 PM, Hirofumi Ichihara
> wrote:

Hi Kevin,

On 2015/12/14 11:10, Kevin Benton wrote:

Hi all,

The availability zone code added a new field to the network
API that shows the availability zones of a network. This
caused a pretty big performance impact to get_networks calls
because it resulted in a database lookup for every network.[1]

I already put a patch up to join the information ahead of
time in the network model.[2]

I agree with your suggestion. I believe that the patch can
solve the performance issue.


However, before we go forward with that, I think we should
consider the removal of that field from the API.

Having to always join to the DHCP agents table to lookup
which zones a network has DHCP agents on is expensive and is
duplicating information available with other API calls.

Additionally, the field is just called 'availability_zones'
but it's being derived solely from AZ definitions in DHCP
agent bindings for that network. To me that doesn't
represent where the network is available, it just says which
zones its scheduled DHCP instances live in. If that's the
purpose, then we should just be using the DHCP agent API for
this info and not impact the network API.

I don't think so. I have three points.

1. Availability zone is implemented in just a case with Agent
now, but it's reference implementation. For example, we
should expect that availability zone will be used by plugin
without agent.

2. In users view, availability zone is related to network
resource. On the other hand, users doesn't need to consider
Agent or operators doesn't like to enable users to do in the
first place. So I don't agree with using Agent API.

3. We should consider whether users want to know the field.
Originally, the field doesn't exist in Spec[3] but I added it
according with reviewer's opinion(maybe Akihiro?). This is
about discussion of use case. After users create resources
via API with availability_zone_hints so that they achieve HA
for their service, they want to know which zones are their
resources hosted on because their resources might not be
distributed on multiple availability zones by any reasons. In
the case, they need to know "availability_zones" for the
resources via Network API.

Thanks,
Hirofumi

[3]: https://review.openstack.org/#/c/169612/31



Thoughts?

1. https://bugs.launchpad.net/neutron/+bug/1525740
2. https://review.openstack.org/#/c/257086/

-- 
Kevin Benton




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 

Re: [openstack-dev] [neutron] - availability zone performance regression and discussion about added network field

[Hirofumi Ichihara]

On 2015/12/14 14:52, Kevin Benton wrote:
I see, so regular users are supposed to use this information as well. 
But how are they supposed to use it? For example, if they see that 
their network has availability zones 1 and 4, but their instance is 
hosted in zone 3, what are they supposed to do?
I don't think that there is what they should do in the case because 
Neutron AZ is different from Nova AZ. For example, there may be a case 
like the following.


1. User throws POST Network API and Subnet API with 
availability_zone_hints [AZ1, AZ2]
2. Neutron server tries to schedule the resource on both AZ1 and AZ2 but 
the resource are scheduled on AZ1 only by some reasons
3. User confirms via GET Network API where his resource is hosted and he 
knows it's AZ1 only

4. User also can know AZ is ready via GET Availability zones API: AZ1, AZ3
5. User deletes previous resource and he recreates his resource with 
availability_zone_hints [AZ1, AZ3]




On Sun, Dec 13, 2015 at 8:57 PM, Hirofumi Ichihara 
> wrote:


Hi Kevin,

On 2015/12/14 11:10, Kevin Benton wrote:

Hi all,

The availability zone code added a new field to the network API
that shows the availability zones of a network. This caused a
pretty big performance impact to get_networks calls because it
resulted in a database lookup for every network.[1]

I already put a patch up to join the information ahead of time in
the network model.[2]

I agree with your suggestion. I believe that the patch can solve
the performance issue.


However, before we go forward with that, I think we should
consider the removal of that field from the API.

Having to always join to the DHCP agents table to lookup which
zones a network has DHCP agents on is expensive and is
duplicating information available with other API calls.

Additionally, the field is just called 'availability_zones' but
it's being derived solely from AZ definitions in DHCP agent
bindings for that network. To me that doesn't represent where the
network is available, it just says which zones its scheduled DHCP
instances live in. If that's the purpose, then we should just be
using the DHCP agent API for this info and not impact the network
API.

I don't think so. I have three points.

1. Availability zone is implemented in just a case with Agent now,
but it's reference implementation. For example, we should expect
that availability zone will be used by plugin without agent.

2. In users view, availability zone is related to network
resource. On the other hand, users doesn't need to consider Agent
or operators doesn't like to enable users to do in the first
place. So I don't agree with using Agent API.

3. We should consider whether users want to know the field.
Originally, the field doesn't exist in Spec[3] but I added it
according with reviewer's opinion(maybe Akihiro?). This is about
discussion of use case. After users create resources via API with
availability_zone_hints so that they achieve HA for their service,
they want to know which zones are their resources hosted on
because their resources might not be distributed on multiple
availability zones by any reasons. In the case, they need to know
"availability_zones" for the resources via Network API.

Thanks,
Hirofumi

[3]: https://review.openstack.org/#/c/169612/31



Thoughts?

1. https://bugs.launchpad.net/neutron/+bug/1525740
2. https://review.openstack.org/#/c/257086/

-- 
Kevin Benton



__
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




--
Kevin Benton


__
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] [neutron] - availability zone performance regression and discussion about added network field

[Kevin Benton]

What decision would lead the user to request AZ1 and AZ2 in the first
place? Especially since when it fails to get AZ2, they just request again
with AZ1 and AZ3 instead.

On Sun, Dec 13, 2015 at 10:31 PM, Hirofumi Ichihara <
ichihara.hirof...@lab.ntt.co.jp> wrote:

>
>
> On 2015/12/14 14:52, Kevin Benton wrote:
>
> I see, so regular users are supposed to use this information as well. But
> how are they supposed to use it? For example, if they see that their
> network has availability zones 1 and 4, but their instance is hosted in
> zone 3, what are they supposed to do?
>
> I don't think that there is what they should do in the case because
> Neutron AZ is different from Nova AZ. For example, there may be a case like
> the following.
>
> 1. User throws POST Network API and Subnet API with
> availability_zone_hints [AZ1, AZ2]
> 2. Neutron server tries to schedule the resource on both AZ1 and AZ2 but
> the resource are scheduled on AZ1 only by some reasons
> 3. User confirms via GET Network API where his resource is hosted and he
> knows it's AZ1 only
> 4. User also can know AZ is ready via GET Availability zones API: AZ1, AZ3
> 5. User deletes previous resource and he recreates his resource with
> availability_zone_hints [AZ1, AZ3]
>
>
>
> On Sun, Dec 13, 2015 at 8:57 PM, Hirofumi Ichihara <
> ichihara.hirof...@lab.ntt.co.jp> wrote:
>
>> Hi Kevin,
>>
>> On 2015/12/14 11:10, Kevin Benton wrote:
>>
>> Hi all,
>>
>> The availability zone code added a new field to the network API that
>> shows the availability zones of a network. This caused a pretty big
>> performance impact to get_networks calls because it resulted in a database
>> lookup for every network.[1]
>>
>> I already put a patch up to join the information ahead of time in the
>> network model.[2]
>>
>> I agree with your suggestion. I believe that the patch can solve the
>> performance issue.
>>
>> However, before we go forward with that, I think we should consider the
>> removal of that field from the API.
>>
>> Having to always join to the DHCP agents table to lookup which zones a
>> network has DHCP agents on is expensive and is duplicating information
>> available with other API calls.
>>
>> Additionally, the field is just called 'availability_zones' but it's
>> being derived solely from AZ definitions in DHCP agent bindings for that
>> network. To me that doesn't represent where the network is available, it
>> just says which zones its scheduled DHCP instances live in. If that's the
>> purpose, then we should just be using the DHCP agent API for this info and
>> not impact the network API.
>>
>> I don't think so. I have three points.
>>
>> 1. Availability zone is implemented in just a case with Agent now, but
>> it's reference implementation. For example, we should expect that
>> availability zone will be used by plugin without agent.
>>
>> 2. In users view, availability zone is related to network resource. On
>> the other hand, users doesn't need to consider Agent or operators doesn't
>> like to enable users to do in the first place. So I don't agree with using
>> Agent API.
>>
>> 3. We should consider whether users want to know the field. Originally,
>> the field doesn't exist in Spec[3] but I added it according with reviewer's
>> opinion(maybe Akihiro?). This is about discussion of use case. After users
>> create resources via API with availability_zone_hints so that they achieve
>> HA for their service, they want to know which zones are their resources
>> hosted on because their resources might not be distributed on multiple
>> availability zones by any reasons. In the case, they need to know
>> "availability_zones" for the resources via Network API.
>>
>> Thanks,
>> Hirofumi
>>
>> [3]: https://review.openstack.org/#/c/169612/31
>>
>>
>> Thoughts?
>>
>> 1. https://bugs.launchpad.net/neutron/+bug/1525740
>> 2. https://review.openstack.org/#/c/257086/
>>
>> --
>> Kevin Benton
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>>
>>
>
>
> --
> Kevin Benton
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage