[openstack-dev] 答复: [quantum] [LBaaS] Health monitors REST resource
Salvatore Orlando
sorlando at nicira.com
Tue Dec 4 17:38:37 UTC 2012
Hi Leon,
sure we'd like to move as swiftly as possible.
If we can't get to a decision quickly (say tomorrow), It will make
sense to just implement the API as it is today with no change, and
defer further discussion to Grizzly-3.
Salvatore
On 4 December 2012 17:19, Leon Cui <lcui at vmware.com> wrote:
> Approach 2 looks good to have a single API to configure a pool at once.
> I'd prefer to go with it and move quickly some other changes (include
> mine) are pending on this change.
>
> Thanks
> Leon
>
>
> -----邮件原件-----
> 发件人: Salvatore Orlando [mailto:sorlando at nicira.com]
> 发送时间: 2012年12月4日 2:07
> 收件人: OpenStack Development Mailing List
> 主题: Re: [openstack-dev] [quantum] [LBaaS] Health monitors REST resource
>
> Hi again!
>
> There has been some apparent silence on this thread. I say 'apparent'
> because actually Oleg pushed a patch to gerrit for dealing with
> subresources, and the discussion kind of moved there, as it's a lot more
> convenient to discuss code.
>
> Anyway, since nobody else chimed in on the gerrit discussion, we are
> moving it back here now.
> This is a summary. If you want all the details (and the code, of course),
> you'll find them here:
> https://review.openstack.org/#/c/16888/
>
> While approach #4 was discarded as it did not match the conceptual LB
> model, we are looking at how get the best of the remaining approaches
> Youcef summarized, namely #2 and #3. (The first approach can probably be
> reduced to #3 if we all agree that the 'health_monitors' collection is
> still an attribute of the 'pool' resource).
> While it seems there's wide agreement on being able to operate on
> health_monitors as a collection (ie: adding/removing single entries), the
> bit that we are still discussing is whether health_monitors should be
> treated as any other attribute or as a special attribute. To the wider
> audience, I just would like to remind here we're discussion on
> "references" to health monitors, or basically a list of ids, rather than
> the health_monitors resources themselves, which are already being treated
> as first level resources.
>
> - Alternative 1
>
> POST /pools
> { ...pool stuff...}
>
> And then
> POST /pools/<pool-id>/health_monitors
> [{"id":"id1"}, {"id": "id2"}, {"id": "id3"}]
>
> - Alternative 2
>
> POST /pools
> { ...pool stuff...
> "health_monitors": [{"id":"id1"}, {"id": "id2"}, {"id": "id3"}]
> ... other pool stuff ...
> }
>
> And similarly for PUT, and GET.
> The following operations will be allowed in both cases:
>
> POST /pools/<pool_id>/health_monitors
> {"id": <id>}
> and
> DELETE /pools/<pool_id>/health_monitors/<id>
>
> The above linked patch is an enhancement of the Quantum API framework for
> dealing with "collection attributes". It is important to note that we have
> plenty of them across the Quantum API. For instance, there is 'fixed_ips'
> in 'port', or 'dns_nameservers' in subnets. It is therefore important that
> the way in which user interacts with this kind of attribute is consistent
> across the whole API; it is even more important to not introduce any
> backward incompatible change while ensuring this consistency. This is
> something that we need to take into account while making a final decision.
> I have a feeling that the 2nd alternative will allow to do so, and will
> also avoid user from having to do two API calls when just one might be
> required.
>
> Salvatore
>
>
> On 27 November 2012 02:15, Youcef Laribi <Youcef.Laribi at eu.citrix.com>
> wrote:
>> Just to summarize agreements and discussed alternatives on this topic
>> so far.
>>
>>
>>
>> On pool members, I think we all agree that the workflow should be:
>>
>>
>>
>> 1. Create an empty pool (we remove the ability to specify
> “members”
>> during this pool creation call).
>>
>> 2. Create members for this pool (pool_id of member is required)
>>
>>
>>
>> On health monitors, here are the alternatives we have discussed so far:
>>
>>
>>
>> 1. Approach one : “health_monitors” subresource (this is the
> current
>> approach documented in API spec):
>>
>> a. Associate health_monitors with a pool:
>>
>> POST /pools/{pool_id}/health_monitors
>>
>> b. Dissociate a health_monitor with a pool
>>
>> DELETE /pools/{pool_id}/health_monitors/{health_monitor_id}
>>
>> c. Retrieve health_monitors associated with pool
>>
>> GET /pools/{pool_id}/health_monitors
>>
>> d. Retrieve pools associated with a health_monitor : No direct API
>> (client has to query all pools and work it out).
>>
>>
>>
>> 2. Approach two: A “health_monitors” attribute in pool resource
> that
>> can be updated.
>>
>> a. Associate health_monitors with a pool. Can be done either:
>>
>> i.
> When
>> the user creates a pool (specifies the health_monitors attribute in
>> the
>> request)
>>
>> POST /pools/{pool_id}
>>
>> ii.
> When
>> the user updates a pool
>>
>> 1. User retrieves the current health_monitors associated with pool
>>
>> GET /pools/{pool_id}
>>
>> 2. User adds new health_monitors and updates this list attribute
> by
>> calling
>>
>> PUT /pools/{pool_id} (this overrides/replaces current list)
>>
>> b. Dissociate a health_monitor with a pool:
>>
>> i.
> Can
>> be done by updating the pool
>>
>> 1. User retrieves the current health_monitors associated with pool
>>
>> GET /pools/{pool_id}
>>
>> 2. User removes health_monitors of interest and updates this
>> attribute by calling
>>
>> PUT /pools/{pool_id} (this overrides/replaces current list)
>>
>> c. Retrieve health_monitors associated with pool
>>
>> GET /pools/{pool_id}
>>
>> d. Retrieve pools associated with a health_monitor : No direct API
>> (client has to query all pools and work it out).
>>
>>
>>
>> 3. Approach three: “health_monitors” subresource for
>> associate/dissociate only.
>>
>> a. Associate health_monitors with a pool (similar to current
> approach)
>>
>> POST /pools/{pool_id}/health_monitors
>>
>> b. Dissociate a health_monitor with a pool (similar to current
>> approach)
>>
>> DELETE /pools/{pool_id}/health_monitors/{health_monitor_id}
>>
>> c. Retrieve health_monitors associated with pool
>>
>> GET /pools/{pool_id} (response contains “health_monitors” list
>> attribute)
>>
>> d. Retrieve pools associated with a health_monitor
>>
>> GET /health_monitors/{health_monitor_id} (response contains “pools”
>> list
>> attribute)
>>
>>
>>
>> 4. Approach four: A new “health_monitor_template” resource.
>>
>> a. Create a health_monitor template
>>
>> POST /health_monitor_templates (in this request we specify all the
>> health_monitor attributes and we get back a template ID – similar to
>> current approach of creating a health monitor resource).
>>
>> b. Associate health_monitors with a pool (this creates a
> health_monitor
>> resource owned by the pool)
>>
>> POST /health_monitors
>>
>> {
>>
>> "health_monitor_template_id": "another-uuid",
>>
>> "pool_id": "yet-another-uuid"
>>
>> }
>>
>> c. Dissociate a health_monitor from its pool (this removes the
>> health_monitor from its owning pool)
>>
>> DELETE /health_monitors/{health_monitor_id}
>>
>> d. Retrieve all health_monitors associated with pool
>>
>> GET /health_monitors?pool_id=1000 (do we support filtering on
>> collections in the API)
>>
>> e. Retrieve pools associated with a health_monitor template
>>
>> GET /health_monitors?health_monitor_template_id=7281
>>
>>
>>
>>
>>
>> Youcef
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: Salvatore Orlando [mailto:sorlando at nicira.com]
>> Sent: Thursday, November 22, 2012 1:27 PM
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [quantum] [LBaaS] Health monitors REST
>> resource
>>
>>
>>
>> Hi again,
>>
>>
>>
>> For health monitors, I think we are discussing two equally viable
>> approaches. Both have pro and cons. As Youcef said, introducing a
> 'template'
>> for the health monitor adds a new resource, and an intermediate step
>> we probably don't want to expose to the user; I personally see the
>> fact that health monitors are usually mapped 1:1 on correspoinding
>> back-end API as somewhat less relevant, as I'd like to adopt a
>> perspective completely focused on the user. On the other hand, we have
>> discussed the cons of handling reference to health monitors as a
>> collection attribute within pools. I am taking for granted that you
>> are discounting the idea of having a 'list' attribute (as fixed_ips
>> for the port resource), even if that is not perfect as well it probably
> is the simplest from a user perspective.
>>
>>
>>
>> If we go the sub-resource-like route (current proposal), we'll need to
>> do some work on the Quantum API framework for supporting it. I will be
>> more than happy to this piece of work.
>>
>>
>>
>> For pool members, I'd rather have a single way of doing thing rather
>> than two. I think it is more natural to specify the pool_id in the
>> member resource.
>>
>>
>>
>> Thanks,
>>
>> Salvatore
>>
>>
>>
>>
>>
>> On 22 November 2012 20:37, Youcef Laribi <Youcef.Laribi at eu.citrix.com>
>> wrote:
>>
>> Hi Oleg,
>>
>>
>>
>> My intention was to keep the same APIs we have for
>> associating/dissociating a pool with a health_monitor. The new APIs
>> will be used for retrieving (GET).
>>
>>
>>
>> Yes, I know it’s not ideal because a health_monitor looks like a
>> sub-resource of pool in the associate/dissociate calls (doing it the
>> other way around is no better either), but I don’t think it’s a big
>> deal from a user perspective, and will keep the API simple instead of
>> introducing a new REST entity.
>>
>>
>>
>> Thanks
>>
>> Youcef
>>
>>
>>
>>
>>
>>
>>
>> From: Oleg Bondarev [mailto:obondarev at mirantis.com]
>> Sent: Thursday, November 22, 2012 2:05 AM
>>
>>
>> To: 'OpenStack Development Mailing List'
>> Subject: Re: [openstack-dev] [quantum] [LBaaS] Health monitors REST
>> resource
>>
>>
>>
>> Hi Youcef,
>>
>> I have one question here: with what API calls do you suggest to
>> associate/disassociate health monitors with a pool?
>>
>>
>>
>> Thanks,
>>
>> Oleg
>>
>>
>>
>> From: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
>> Sent: Thursday, November 22, 2012 12:12 AM
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [quantum] [LBaaS] Health monitors REST
>> resource
>>
>>
>>
>> Hi Salvatore,
>>
>>
>>
>> Thank you for your thorough analysis and helping the team reconcile a
>> good API design with an easy way to implement it.
>>
>>
>>
>> I think we need to make a distinction between pool members and health
>> monitors.
>>
>> Indeed the former exist only within a pool [1], whereas the latter can
>> be defined without any pool [2].
>>
>> So for the pool members, I agree we probably don't want to specify
>> them in API calls for 'pool' resources.
>>
>> In particular [3] seems strange in my opinion, as it is assuming the
>> members already exist. In another thread I think there was a
>> suggestion to make the member's pool_id attribute optional, but my
>> opinion is that probably we should remove the members attribute for
>> the pool resource (at least on create/update calls). It is fine IMHO
>> to return a list of member ids on GET operations for pools.
>>
>>
>>
>> Yes today we have two ways of putting members into pools:
>>
>> 1. Create an empty pool, and then create members using the created
>> pool_id
>>
>> 2. Create members (with no pool_id) and then create a pool
> containing
>> those members
>>
>>
>>
>> We can eliminate the second workflow to simplify as you suggested, so
>> there would be only one way of creating members in pools.
>>
>>
>>
>> The question after this, is how do I get the members of a pool (a very
>> common operation). Here again, we have three possible ways:
>>
>>
>>
>> 1. Use filtering: GET /members?pool_id=1000
>>
>> 2. Have a dedicated REST API that reflects the fact the members
> belong
>> to a pool: GET /pools/1000/members
>>
>> 3. Return the list of members of a pool in the pool response
> payload
>> of: GET /pools/1000
>>
>>
>>
>> I favor the second approach but I can settle for the 3rd one, even
>> though this requires more work from a user to find the “members”
>> attribute on the response. What is your opinion on this?
>>
>>
>>
>> Instead the health monitors are slightly different, since they are in
>> a n:m relationship with the pool resource. pool and pool members are
>> instead on a 1:n relationship.
>>
>> The approach currently adopted in the API specification [4] makes
>> sense from a REST perspective. IMHO it makes more sense than having
>> distinct member action such as:
>>
>> PUT /pools/<pool-id>/associate_health_monitor and PUT
>> /pools/<pool-id>/disassociate_health_monitor. As some contributors to
>> this thread have pointed out, this can generate confusion in final
>> users, as they might wonder whether an id or a full object definition
>> is required. In that case I would consider the following:
>>
>>
>>
>> {POST/DELETE} /pools/<pool-id>/health_monitor_ids
>>
>>
>>
>> Sub-resources map very well onto a ORM model.
>>
>>
>>
>> Yes we are on the same page here, although I favor calling the
>> sub-resource simply “health_monitors” instead of
> “health_monitor_ids”
>> or “health_monitor_references”, purely from an aesthetic perspective,
>> but I haven’t got a strong opinion on this.
>>
>>
>>
>> However, let's imagine you want to retrieve the list of pools which
>> are using a health_monitor. How would you do that? In theory you could
>> add that filter to the pools resource, so:
>>
>>
>>
>> GET /pools?health_monitor_id=<your_health_monitor> would return you
>> this kind of list.
>>
>>
>>
>> With this approach it is important to keep in mind is that a GET
>> /pools is supposed to look only into 'pool' resources. Adding this
>> kind of capability would require us to do joins according to the type
>> of filter specified (and we will also have to document it). No big
>> deal, but still something to keep in mind.
>>
>>
>>
>> Yes this call doesn’t make sense since there is currently no attribute
>> called “health_monitor_id” in a pool resource you can filter on. User
>> can accomplish this themselves by retrieving all pool’s health monitor
>> associations, and filtering the ones that contain the health_monitor
>> of interest
>>
>>
>>
>> GET /pools/1000/health_monitors
>>
>> GET /pools/2000/health_monitors
>>
>>
>>
>> Etc.
>>
>>
>>
>> After all, these kind of request “which pools use monitor X” are not
>> very common or necessary for the workflow of the service. There would
>> be a lot many more questions like this that cannot be directly mapped
>> to an API call, and need the user to do some filtering and joining on
> their own.
>>
>>
>>
>> An alternative is to regard the health_monitor as a 'template'. I am
>> not sure if this is valid within the LB world, but I have the
>> impression it is ok to assume that a health monitor does not actually
>> exist until it is associated with a pool.
>>
>>
>>
>> In NetScaler, F5 and similar products, health monitors are created
>> beforehand just like in the API, and then they are “bound” to pools
>> (our association API), so the mapping will be more natural.
>>
>>
>>
>> In this case 'definitions' for health monitors could be managed in the
>> following way:
>>
>>
>>
>> { GET/POST/PUT/DELETE } /health-monitor-templates
>>
>>
>>
>> And association/disassociation with pools can be managed in the
>> following
>> way:
>>
>>
>>
>> {GET/POST/DELETE} /health-monitors
>>
>>
>>
>> The response here would look like the following:
>>
>>
>>
>> {
>>
>> "health_monitor_id": "uuid",
>>
>> "health_monitor_template_id": "another-uuid",
>>
>> "pool_id": "yet-another-uuid"
>>
>> }
>>
>>
>>
>> I think both approaches are equivalent. The first is represents a good
>> mapping on the ORM model, while the second a mapping on the ER model.
>>
>> The first will need work to the Quantum's framework, whereas the
>> latter can be implemented using the framework as it is.
>>
>> I have a slight preference for the second option, but no strong
>> opinion, as I believe the first approach makes sense too.
>>
>>
>>
>> I think adding a concept of health_monitor templates just complicate
>> matters even more. The issue we have is not how to associate monitors
>> and pools, these are simple API calls, but answering the following
>> questions
>>
>>
>>
>> 1. What are the health_monitors associated with a pool?
>>
>> 2. What are the pools associated with a health monitor?
>>
>>
>>
>> I propose when retrieving a pool, we simply return the list of
>> health_monitors associated with it, and for a health_monitor the list
>> of pools associated with it. These are only returned for GET (they are
>> read-only attributes), they are not used for creation or update (we
>> use the associate/dissociate APIs already there), so this would
>> translate in answering the above questions to this:
>>
>>
>>
>> 1. Health monitors associated with a pool: GET /pools/{pool_id}
>> (response contains a “health_monitors” (or health_monitor_ids J)
>> attribute)
>>
>> 2. Pools associated with a health_monitor: GET
>> /health_monitors/{health_monitor_id} (response contains a “pools”
>> attribute)
>>
>>
>>
>> This way we avoid the issue of sub-resource modeling, and keep the API
>> simple (at a cost of slightly more work for the API caller). What do
>> you think?
>>
>>
>>
>> Youcef
>>
>>
>>
>>
>>
>>
>>
>> On 20 November 2012 09:51, Oleg Bondarev <obondarev at mirantis.com> wrote:
>>
>> Hi Youcef, team,
>>
>>
>>
>> AFAIK python clients (quantum, nova, etc.) usually expose both CLI and
>> python API which I believe should be used in Horizon and other
>> projects. So I still think that python-quantumclient is the right
>> place for adding shortcuts.
>>
>>
>>
>> A agree that improving api/v2 to support sub-resources is a good idea
>> and will be useful. I also agree that “GET
>> /v1.0/pools/{pool_id}/members” looks natural but only in case when
> member is an actual sub-resource of a pool.
>> Resources and sub-resources in the Quantum extension framework are
>> distinctly separated. In our case members and health monitors are top
>> level resources – so adding them also as sub-resources is kind of
>> hack, and may be misleading for those who reads the code – all for the
>> sake of having shortcuts in REST.
>>
>> From my point of view it’s clear enough from our REST API that members
>> belong to a pool since they have pool_id field and pool in its turn
>> has members field.
>>
>>
>>
>> Hey we have a pretty long discussion here J, would be great to hear
>> anybody else from the team and make a final decision.
>>
>> Salvatore, could you please share your thoughts?
>>
>>
>>
>> Thanks,
>>
>> Oleg
>>
>>
>>
>> From: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
>> Sent: Tuesday, November 20, 2012 1:01 AM
>>
>>
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [quantum] [LBaaS] Health monitors REST
>> resource
>>
>>
>>
>> Yes Oleg, some people will use the CLI to drive the LBaaS service,
>> Horizon portal will use the API, and other applications will use mainly
> the API.
>> Most people will understand the service by reading its APIs.
>>
>>
>>
>> Yes, you can list the members of pool 1000 through query string
>> filtering by doing:
>>
>>
>>
>> GET /v1.0/members?pool_id=1000
>>
>>
>>
>> But as I said before, it’s more natural to use the following to get
>> the pool’s members:
>>
>>
>>
>> GET /v1.0/pools/{pool_id}/members
>>
>>
>>
>> Since members really belong to a pool. As you said, if we are
>> improving Quantum to support REST sub-resources then this is the
>> preferred approach I would advocate.
>>
>>
>>
>> Youcef
>>
>>
>>
>> From: Oleg Bondarev [mailto:obondarev at mirantis.com]
>> Sent: Monday, November 19, 2012 1:23 AM
>> To: 'OpenStack Development Mailing List'
>> Subject: Re: [openstack-dev] [quantum] [LBaaS] Health monitors REST
>> resource
>>
>>
>>
>> I also surely agree that “/pools/{pool_id}/health_monitor_references“
>> looks ugly and I don’t want it to look like this.
>>
>> My only concern is that treating health monitor references as a
>> sub-resource (and hence changes in api/v2) brings additional
>> complexity to the code when it can be done simpler: using filters for
>> listing health monitors of a pool and member actions for
>> associate/disassociate (as in l3 extension). But probably it is ok
>> given that handling sub-resources may be useful in future anyway.
>>
>>
>>
>> Another question I have is: where will these REST calls be used except
>> python-quantumclient? I thought that only client api matters for end
> users.
>> So the purpose of having kind of shortcuts for listing members and
>> health monitors of a pool in REST API (instead of using filters) is
>> not completely clear for me.
>>
>>
>>
>> Thanks,
>>
>> Oleg
>>
>>
>>
>> From: Salvatore Orlando [mailto:sorlando at nicira.com]
>> Sent: Friday, November 16, 2012 9:32 PM
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [quantum] [LBaaS] Health monitors REST
>> resource
>>
>>
>>
>> Hi Youcef,
>>
>>
>>
>> Thanks for the clarification. I was pretty sure this was well thought
>> in the API design, as I wrote in my previous post :)
>>
>>
>>
>> The naming for the attribute on the pool which references
>> health_monitors is a discussion worth having. I have very little data
>> points for comparison with other parts of Quantum and Openstack APIs.
>> The only similar bit is probably the network-subnet relationship. In
>> the response for a GET /networks/<network-id> a list of subnet
>> identifiers is returned. The name for the list attribute is just
>> 'subnets'. However, as this is a read-only attribute there is no need
>> for handling it as a sub-resource. Response sample is available at [1]
>>
>>
>>
>> Between handling the collection of health monitor references as a
>> sub-resource and having member actions for CRUD operations, I prefer
>> the first solution. I am happy to offer any kind of supports for the
>> relevant changes in the apiv2 modules. The other option is to regard
>> health_monitors as a 'list' attribute. Which means that a POST/PUT
>> will create/update the whole list. This is practical from server-side
>> perspective, but has also drawbacks. Indeed it adds burden to the
>> client; for instance, in order to add an element to the list you'll
>> need a GET and then a PUT; and it also causes confusion because of the
>> fact that our PUT actually implement patch semantics.
>>
>>
>>
>> Salvatore
>>
>>
>>
>> [1]
>> http://docs.openstack.org/api/openstack-network/2.0/content/List_Netwo
>> rks_Detail.html#d6e858
>>
>>
>>
>> On 16 November 2012 18:04, Youcef Laribi <Youcef.Laribi at eu.citrix.com>
>> wrote:
>>
>> Changing the subject line…
>>
>>
>>
>> Health monitors “/health_monitors/” are a top resource in the API and
>> are retrieved/added/removed/updated through their CRUD operations on
>> this top resource.
>>
>>
>>
>> The subresource “/pools/{pool_id}/health_monitors“ is used for
>> associating already existing health monitors (created above) with an
>> existing pool, or for retrieving the health monitors associated with a
>> pool. It is a collection (list) that only contain IDs of health
>> monitors not the health monitors themselves. We can call this resource
>> “/pools/{pool_id}/health_monitor_references“ or
>> “/pools/{pool_id}/pool_health_monitors” if we like, but I felt this
>> was ugly and I think there is no issue or ambiguity in the definition
>> of API itself as all operations are clearly described. But if you
>> think changing its name helps, I can do that J Would like to hear what
> others in the team think.
>>
>>
>>
>> Youcef
>>
>>
>>
>> From: Oleg Bondarev [mailto:obondarev at mirantis.com]
>> Sent: Friday, November 16, 2012 1:12 AM
>> To: Youcef Laribi; 'OpenStack Development Mailing List'
>> Subject: RE: [openstack-dev] [quantum] Quantum extension framework
>> issue
>>
>>
>>
>> Hi guys,
>>
>>
>>
>> I just want to clarify some things regarding health monitors in LBaaS
> API:
>> actually it is not completely a sub-resource of pool objects.
>>
>> According to the API it is a separate resource which can be
>> added/showed/updated/deleted (with GET/POST..
> “/v1.0/health_monitors/..”
>> rest calls) in order to be reusable in different pools and probably
>> anywhere else as Sasha mentioned. Youcef please correct me if I am wrong
> here.
>>
>> Speaking about sub-resources I think following rest call:
>>
>>
>>
>> POST /v1.0/pools/{pool_id}/health_monitors
>>
>>
>>
>> is intended to create a sub-resource of health monitor for the pool
>> and not to add an existing health monitor to the pool.
>>
>> Also I think having health monitors as a separate resource and as a
>> sub-resource of a pool at the same time is not correct.
>>
>> So my vision is to leave health monitors as a separate resource and to
>> use member actions for the purpose of
>> getting/associating/disassociating health monitors with a pool:
>>
>> Get health monitors of a pool:
>>
>> GET /v1.0/pools/{pool_id}/get_health_monitors
>>
>> Associate health monitors with a pool:
>>
>> PUT /v1.0/pools/{pool_id}/add_health_monitors
>>
>>
>>
>>
>>
>> {
>>
>>
>>
>>
>>
>> "health_monitors" : [
>>
>> "f3eeab00-8367-4524-b662-55e64d4cacb5"
>>
>> ]
>>
>> }
>>
>> Disassociate health monitors from a pool:
>>
>> PUT /v1.0/pools/{pool_id}/delete_health_monitors
>>
>> {
>>
>>
>>
>> "health_monitors" : [
>>
>> "f3eeab00-8367-4524-b662-55e64d4cacb5"
>>
>> ]
>>
>> }
>>
>>
>>
>> Please share your thoughts.
>>
>>
>>
>> Thanks,
>>
>> Oleg
>>
>>
>>
>> From: Sasha Ratkovic [mailto:sasharatkovic at juniper.net]
>> Sent: Friday, November 16, 2012 3:38 AM
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [quantum] Quantum extension framework
>> issue
>>
>>
>>
>> One comment: even though health_monitor is introduced as part of LB
>> effort, it has more general applicability. So having it under LB
>> specific resource may pose usability problems down the road when new
>> services are introduced, if health monitor is to be re-used for that
>> purpose. One solution is to make it "first class" citizen with
> relationship to "pool" and/or make "pool"
>> assume more abstract pooling semantics, reusable as well across
>> multiple services in the future. (yes, I am talking about "groups" here
> :) ).
>>
>>
>>
>> From: Salvatore Orlando <sorlando at nicira.com>
>> Reply-To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>
>> Date: Thursday, November 15, 2012 7:40 AM
>> To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [quantum] Quantum extension framework
>> issue
>>
>>
>>
>> Hi Oleg,
>>
>>
>>
>> This is exactly what I was talking about.
>>
>> One thing you might want to consider before choosing for one direction
>> or the other is that at the moment Quantum API does not use sub
>> resources at all.
>>
>> There was a long discussion on this regard while designing the v2 API.
>> The gist of the discussion was that if a resource needed sub-resources
>> then there was a case for a sub-resource to become a 'first citizen' in
> the API.
>> I am pretty sure you already have mulled over whether health_monitors
>> should be a resource of their own, a sub resource of the pool, or a
>> multi-valued attribute of the pool, but I wanted to give you a heads-up
> anyway.
>>
>>
>>
>> On your technical questions I have some answers inline.
>>
>>
>>
>> Salvatore
>>
>> On 15 November 2012 15:40, Oleg Bondarev <obondarev at mirantis.com> wrote:
>>
>> Hi folks,
>>
>>
>>
>> As Salvatore said there is a way to specify parent for a resource (see
>> quantum.extensions.extensions.ResourceExtension) which allows route
>> mapping for rest calls like:
>>
>>
>>
>> POST /v1.0/pools/{pool_id}/health_monitors
>>
>> DELETE /v1.0/pools/{pool_id}/health_monitors/{id}
>>
>> …
>>
>>
>>
>> In this case corresponding resource controller should be aware of
>> resource parent and be able to handle CRUD operations with an
>> additional parent_id parameter. Currently it doesn’t. Actually I am
>> speaking about quantum.api.v2.base.Controller – so, Salvatore, do you
>> think it is the right place to include sub-resource/parent handling?
>>
>>
>>
>> Working on controllers in quantum.api.v2 is the best option in my
> opinion.
>>
>> This however depends on how the route mapper associates controllers
>> with sub resources. Currently, the extension framework and the core
>> API use two distinct code paths: the former uses
>> quantum.extensions.extensions.ExtensionMiddleware whereas the latter
>> uses quantum.api.v2.router.APIRouter (this is for historical reasons
>> only; as far as I can recall, there's no technical reason for this).
>> The Extension Middleware has a mechanism for mapping associating
>> parent resources to a mapped resource, whereas the APIRouter does not
> have such mechanism.
>>
>>
>>
>> As the controller does not care about how URI paths are mapped on its
>> methods, the only thing we probably need to worry about is how to make
>> sure that the parent resource id is passed to the controller for the
>> sub-resource. To this aim, I would probably define a new controller
>> which extends the base one rather than modifying
> quantum.api.v2.base.Controller.
>>
>> Btw, there is of course the hackish way of skipping
>> base.create_resource and passing to ResourceExtension an object
>> providing implementation for the appropriate methods. I am totally
>> sure you're aware of this option too, but I would consider it only a
> last resort.
>>
>>
>>
>>
>>
>>
>>
>> And also how do you guys think should this improvement be done as a
>> separate patch?
>>
>>
>>
>> Separate patches in these cases are always preferred.
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Oleg
>>
>>
>>
>> From: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
>> Sent: Wednesday, November 14, 2012 11:03 PM
>>
>>
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [quantum] Quantum extension framework
>> issue
>>
>>
>>
>> Oleg,
>>
>>
>>
>> The “/pools/{pool_id}/health_monitors” REST resource is intended to be
>
>> a collection sub-resource of the “/pools/{pool_id}” resource, so if
>> the Quantum WSGI framework can be improved to support REST
>> sub-resources that would be better and cleaner.
>>
>>
>>
>> Youcef
>>
>>
>>
>>
>>
>> From: Salvatore Orlando [mailto:sorlando at nicira.com]
>> Sent: Wednesday, November 14, 2012 10:00 AM
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [quantum] Quantum extension framework
>> issue
>>
>>
>>
>> Hi Oleg,
>>
>>
>>
>> When I read your first email, I had the same impression as Dan.
>>
>> health_monitors look more like a subresource than an action.
>>
>>
>>
>> The WSGI framework at the moment is not able to manage subresources;
>> this does not mean we cannot improve it though. Nevertheless, in this
>> case the route mapping is not performed by the API classes in
>> quantum/api, but by the extension manager. I think there should
>> already be a way for specifying parent resources with extensions, but
> that needs to be explored.
>>
>>
>>
>> It seems however that you are now trying to map operations on health
>> monitors using distinct member actions (add_health_monitor,
>> get_health_monitors). This is similar to what happens with the L3 API
>> for router interfaces.
>>
>> However, it seems the original idea behind the API design was to treat
>> health_monitors as an explicit collection, which would also be
>> probably a more 'restful' way of doing it. I think ultimately the
>> question should be directed to Youcef and the team which contributed
>> to the design of the LBaaS API.
>>
>> On 14 November 2012 17:18, Oleg Bondarev <obondarev at mirantis.com> wrote:
>>
>> Hi Dan,
>>
>> Thanks for your comment here.
>>
>> Just wanted to correct a mistake in my first email: of course there
>> can’t be a dict with duplicate keys. The idea was to use list of pairs,
> like:
>>
>> member_actions = [{“health_monitors”: “GET”},
>>
>> {“health_monitors”:
> “POST”}]
>>
>> to have an ability of using same function name with different request
>> actions. Initially I thought that the framework provides such ability
>> but does not dispatch requests correctly. I was wrong.
>>
>> Actually there is no issue with the framework as it assumes using
>> unique action names for different request methods.
>>
>>
>>
>> I believe we should update LBaaS REST API doc and use
>> “get_health_monitors”, “add_health_monitors”, etc. to fit in the
> framework.
>>
>>
>>
>> Thanks,
>>
>> Oleg
>>
>>
>>
>> From: Dan Wendlandt [mailto:dan at nicira.com]
>> Sent: Wednesday, November 14, 2012 7:27 PM
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [quantum] Quantum extension framework
>> issue
>>
>>
>>
>> Hi Oleg,
>>
>>
>>
>> Folks from the API-subteam can correct me, but I believe this use
>> model is outside of what the API framework was trying to enable with
>> "actions". The idea is that you use POST/DELETE to create an delete
>> API "resources" (which actually have UUIDs, for example, the "pool" in
>> your example below) and then do a PUT to an "action" to cause some
>> kind of change that you can affect on a resource (e.g.,
>> "add_health_monitor" or "remove_health_monitor"). It sounds like what
>> you are proposing is more treating "health_monitors" almost as a
>> "sub-resource", which is not really what the "actions" stuff was
> designed for.
>>
>>
>>
>> I haven't been deeply involved in the LBaaS api design discussion
>> though, so I'd also like to hear from Salvatore, et al. on the API
> sub-team.
>>
>>
>>
>> Dan
>>
>>
>>
>>
>>
>> On Wed, Nov 14, 2012 at 6:05 AM, Oleg Bondarev
>> <obondarev at mirantis.com>
>> wrote:
>>
>> Hi guys,
>>
>>
>>
>> While working on the API extension for LBaaS I didn’t find a way to
>> use custom member actions if they have the same name and differ only
>> by request method, for example
>>
>>
>>
>> List all health monitors of a specific pool: GET
>> /pool/pool_id/health_monitors
>>
>> Associate health monitors with a pool: POST
>> /pool/pool_id/health_monitors
>>
>>
>>
>> In quantum extension framework we pass “health_monitors” as member
>> actions for a controller (quantum.api.v2.base.create_resource())
>>
>>
>>
>> member_actions = {'health_monitors': 'GET',
>>
>> 'health_monitors': 'POST'}
>>
>>
>>
>> controller = base.create_resource(collection_name,
>>
>> resource_name,
>>
>> plugin, params,
>>
>> member_actions=member_actions)
>>
>>
>>
>> According to the Controller implementation it dispatches all custom
>> member actions to its plugin attr:
>>
>>
>>
>> def __getattr__(self, name):
>>
>> if name in self._member_actions:
>>
>> def _handle_action(request, id, body=None):
>>
>> return getattr(self._plugin, name)(request.context,
>> id,
>> body)
>>
>> return _handle_action
>>
>> else:
>>
>> raise AttributeError
>>
>>
>>
>> Where request.context is of type quantum.context.Context and does not
>> contain info about request method.
>>
>> As a result there is no way to distinguish two custom actions in the
> plugin.
>>
>> Is it an issue in the framework?
>>
>>
>>
>> Possible solution may be in concatenation of request method and action
>> name (“get_health_monitors”, “post_health_monitors”) in a controller
>
>> before dispatching them to a plugin.
>>
>> What do you think?
>>
>>
>>
>> Thanks,
>>
>> Oleg
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Dan Wendlandt
>>
>> Nicira, Inc: www.nicira.com
>>
>> twitter: danwendlandt
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list