Open Stack

My 2 notes on the topic :)
1) It is not an option to use "GET /members/{member_id}" for retrieving
health status, since it needs to call the driver/device (and thus become
asynchronous). I vote for a separate method that retrieves health data,
actually it may be similar to "get_stats".
2) Not all load balancers able to map the health status back to health
monitor (HAProxy is an example). We may consider the following response:

{
    "status": "FAIL",
    "ext_code": "L4_CON",
    "details": "Connection refused (tcp rst)",
    "health_monitor_id": "f3eeab00-8367-4524-b662-55e64d4cacb5"
}

where attributes 'ext_code' and 'health_monitor_id' are optional.

Thanks,
Ilya

2012/11/27 Leon Cui <lcui at vmware.com>

> Youcef/Peter,****
>
> Yes it sounds good to me.****
>
> ** **
>
> Thanks****
>
> Leon****
>
> *发件人**:* Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
> *发送时间:* 2012年11月26日 17:20
>
> *收件人:* OpenStack Development Mailing List
> *主题:* Re: [openstack-dev] 答复: [Quantum] [LBaaS] Health Monitor Failure
> Detection****
>
> ** **
>
> Hi Leon,****
>
> ** **
>
> Yes, as Peter pointed out, user needs to know which health check has
> failed. Whether we want this information to appear in the existing “GET
> /members/{member_id}” or whether we want to have a new API for “GET
> /members/{member_id}/details”, I’m fine with both. Currently however, we do
> not have “/details” sub-resource for any other resource (it’s not a pattern
> we are following in the API), so I see introducing it just for this case
> may be an overkill.****
>
> ** **
>
> Thanks****
>
> Youcef ****
>
> ** **
>
> *From:* Mellquist, Peter [mailto:peter.mellquist at hp.com]
> *Sent:* Monday, November 26, 2012 2:58 PM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] 答复: [Quantum] [LBaaS] Health Monitor
> Failure Detection****
>
> ** **
>
> Hi Leon,****
>
> ** **
>
> The admin / user needs to know the specific health monitor which has
> failed so that they may take appropriate action to fix the member with the
> failed health check. If we not provide this detail, then the root cause on
> why the member has gone “inactive” will be unknown. Most JSON parsers allow
> parsing fields of interest and ignoring others so it should not be an issue
> for clients who are not interested in health monitors but … that being said
> as we continue to work out important use cases, like this one, we may find
> that a refactoring of the REST resources may be needed. I see this as an
> iterative process.****
>
> ** **
>
> Thanks,****
>
> Peter.****
>
> ** **
>
> *From:* Leon Cui [mailto:lcui at vmware.com <lcui at vmware.com>]
> *Sent:* Thursday, November 22, 2012 4:49 PM
> *To:* 'OpenStack Development Mailing List'
> *Subject:* [openstack-dev] 答复: [Quantum] [LBaaS] Health Monitor Failure
> Detection****
>
> ** **
>
> Hi Peter and Youcef,****
>
> Showing the health monitor status details in member might be too much for
> user.  In most time, user (and Mgmt UI) might be only interested in the
> overall pool/member status unless user wants to drill down to the details.
> My concern is that we are adding more and more details in the top resource
> GET API which add more payload and complex to parse. I’m wondering if we
> can add a separate API GET /resource/<resource_id>/details which can expose
> more detailed information for each resource.****
>
> ** **
>
> Just my 2 cents.****
>
> ** **
>
> Thanks****
>
> Leon****
>
> *发件人**:* Mellquist, Peter [mailto:peter.mellquist at hp.com<peter.mellquist at hp.com>]
>
> *发送时间:* 2012年11月22日 5:06
> *收件人:* OpenStack Development Mailing List
> *主题:* Re: [openstack-dev] [Quantum] [LBaaS] Health Monitor Failure
> Detection****
>
> ** **
>
> Hi Youcef,****
>
> ** **
>
> This looks like it will work fine. I like this since it shows the state of
> all the monitors for the member.****
>
> ** **
>
> Peter.****
>
> ** **
>
> ** **
>
> *From:* Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com<Youcef.Laribi at eu.citrix.com>]
>
> *Sent:* Wednesday, November 21, 2012 12:34 PM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Quantum] [LBaaS] Health Monitor Failure
> Detection****
>
> ** **
>
> Hi Peter,****
>
> ** **
>
> Yes you bring up a good point that we missed in the API. Usually in LB
> products when user displays the member, then the monitors used to monitor
> the member and their status are also displayed. We can adopt the same
> approach as follows:****
>
> ** **
>
> "member" :  {****
>
>                 "id":"c57f581b-c834-408f-93fa-30543cf30618",****
>
>                 "tenant_id": "310df60f-2a10-4ee5-9554-98393092194c",****
>
>                 "pool_id": "cfc6589d-f949-4c66-99d2-c2da56ef3764",****
>
>                 "address": "192.168.224.31",****
>
>                 "port": 8080,****
>
>                "weight" : 1,****
>
>                 "admin_state_up" : *true*,****
>
>                 "status" : "INACTIVE",****
>
>                 "health_monitors_status" : [****
>
>                      {****
>
>                         "health_monitor_id" :
> "f3eeab00-8367-4524-b662-55e64d4cacb5",****
>
>                         "status" : "FAIL"****
>
>                      },****
>
>                      {****
>
>                         "health_monitor_id" : "
> 70995ff0-341a-11e2-81c1-0800200c9a66",**
>
>                         "status" : "SUCCESS"****
>
>                      }****
>
> ** **
>
>                 ]****
>
>               }****
>
> ** **
>
> Would this  be acceptable?****
>
> ** **
>
> Youcef****
>
> ** **
>
> ** **
>
> *From:* Mellquist, Peter [mailto:peter.mellquist at hp.com<peter.mellquist at hp.com>]
>
> *Sent:* Wednesday, November 21, 2012 11:17 AM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] Quantum LBaaS Health Monitor Failure Detection*
> ***
>
> ** **
>
> Hi LBaaS’ers,****
>
> ** **
>
> With the current capability to associate multiple health monitors with a
> pool, it does not seem possible to see which specific health monitor has
> detected an issue. For example, If I have a PING and HTTP monitor and the
> HTTP monitor fails how can the user or admin have visibility into the
> specific failure?****
>
> “When a pool has several monitors associated with it, each member of the
> pool is monitored by all these monitors. If any monitor declares the member
> as unhealthy, then the member status is changed to INACTIVE and the member
> won't participate in its pool's load balancing. In other words, ALL
> monitors must declare the member to be healthy for it to stay ACTIVE. “***
> *
>
> Member status changing to INACTIVE does not describe the reason why.
> Would  it make sense to have a member status reason with the reference to
> the health monitor id in this case? We could then see which health monitor
> is failing and allow the user or admin to take appropriate action.****
>
> ** **
>
> Peter.****
>
> "member" :  {****
>
>                 "id":"c57f581b-c834-408f-93fa-30543cf30618",****
>
>                 "tenant_id": "310df60f-2a10-4ee5-9554-98393092194c",****
>
>                 "pool_id": "cfc6589d-f949-4c66-99d2-c2da56ef3764",****
>
>                 "address": "192.168.224.31",****
>
>                 "port": 8080,****
>
>                "weight" : 1,****
>
>                 "admin_state_up" : *true*,****
>
>                 "status" : "INACTIVE",****
>
>                 "status_reason" : "f3eeab00-8367-4524-b662-55e64d4cacb5"**
> **
>
>               }                                             ****
>
> ** **
>
> {****
>
>     "health_monitor" :****
>
>       {****
>
>          "id" : "f3eeab00-8367-4524-b662-55e64d4cacb5",****
>
>          "type" : "HTTP",****
>
>          "delay" : 20,****
>
>          "timeout": 10,****
>
>          "max_retries": 3,****
>
>          "http_method" : "GET",****
>
>          "url_path" : "/",****
>
>          "expected_codes" : "200,202",****
>
>          "admin_state_up": *true*,****
>
>          "status": "ACTIVE"****
>
>       }****
>
> }****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121127/caee9a4b/attachment-0001.html>