Re: [openstack-dev] [telemetry][aodh] "aodh alarm list" vs "aodh alarm search"
Thanks for this discussion and the agreement, it sounds good, I will upload related changes. -- Liu sheng 在 2016/3/7 23:42, gordon chung 写道: On 07/03/2016 8:05 AM, Julien Danjou wrote: On Mon, Mar 07 2016, gordon chung wrote: shall we drop 'alarm search' nomenclature and use just 'alarm list' for both queries (standard and complex). the concern i have right now is the proposal is to add standard query support to 'alarm list' while complex query support is in 'alarm search'. this is very confusing especially because both commands use '--query' as their option input. So you have to differentiate 2 things: the REST API and the CLI. You can't merge both on the REST API side, because the complex query system require to send a JSON object, so that requires a POST – whereas listing is simply done via GET. That part we can't merge together. Now, if your plan is to merge both command on the CLI side, I see no objection. That's probably a good UX point. yeah, the proposal is to merge on the client side. let's do that, since it was same way we were leaning at the meeting[1]. 1. drop aodh alarm search 2. add both --query and --complex-query support to aodh alarm list [1] http://eavesdrop.openstack.org/meetings/telemetry/2016/telemetry.2016-03-03-15.01.log.html cheers, __ 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] [telemetry][aodh] "aodh alarm list" vs "aodh alarm search"
On 07/03/2016 8:05 AM, Julien Danjou wrote: > On Mon, Mar 07 2016, gordon chung wrote: > >> shall we drop 'alarm search' nomenclature and use just 'alarm list' for >> both queries (standard and complex). the concern i have right now is the >> proposal is to add standard query support to 'alarm list' while complex >> query support is in 'alarm search'. this is very confusing especially >> because both commands use '--query' as their option input. > > So you have to differentiate 2 things: the REST API and the CLI. > You can't merge both on the REST API side, because the complex query > system require to send a JSON object, so that requires a POST – whereas > listing is simply done via GET. That part we can't merge together. > > Now, if your plan is to merge both command on the CLI side, I see no > objection. That's probably a good UX point. > yeah, the proposal is to merge on the client side. let's do that, since it was same way we were leaning at the meeting[1]. 1. drop aodh alarm search 2. add both --query and --complex-query support to aodh alarm list [1] http://eavesdrop.openstack.org/meetings/telemetry/2016/telemetry.2016-03-03-15.01.log.html cheers, -- gord __ 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] [telemetry][aodh] "aodh alarm list" vs "aodh alarm search"
On Mon, Mar 07 2016, gordon chung wrote: > shall we drop 'alarm search' nomenclature and use just 'alarm list' for > both queries (standard and complex). the concern i have right now is the > proposal is to add standard query support to 'alarm list' while complex > query support is in 'alarm search'. this is very confusing especially > because both commands use '--query' as their option input. So you have to differentiate 2 things: the REST API and the CLI. You can't merge both on the REST API side, because the complex query system require to send a JSON object, so that requires a POST – whereas listing is simply done via GET. That part we can't merge together. Now, if your plan is to merge both command on the CLI side, I see no objection. That's probably a good UX point. -- Julien Danjou # Free Software hacker # https://julien.danjou.info signature.asc Description: PGP signature __ 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] [telemetry][aodh] "aodh alarm list" vs "aodh alarm search"
On 07/03/2016 3:15 AM, Julien Danjou wrote: > On Fri, Mar 04 2016, liusheng wrote: > >> Hi folks, >> Currently, we have supported "aodh alarm list" and "aodh alarm search" >> commands >> to query alarms. They both need mandatory "--type" parameter, and I want to >> drop the limitation[1]. if we agree that, the "alarm list" will only used to >> list all alarms and don't support any query pamareters, it will be equal to >> "alarm search" command without any --query parameter specified. The "alarm >> search" command is designed to support complex query which can perform almost >> all the filtering query, the complex query has been supportted in Gnocchi. >> IRC >> meeting disscussions [3]. >> >> So we don't need two overlapping interfaces and want to drop one, "alarm >> list" >> or "alarm search" ? >> >> i. The "alarm search" need users to post a expression in JSON format to >> perform >> spedific query, it is not easy to use and it is unlike a customary practice >> (I >> mean the most common usages of filtering query of other openstack projects), >> compare to "alarm list --filter xxx=zzz" usage. >> >> ii. we don't have a strong requirement to support *complex* query scenarios >> of >> alarms, we only have alarms and alarm history records in aodh. >> >> iii. I personally think it is enough to support filtering query with >> "--filter" >> which is easy to implement [2], and, we have plan to support pagination query >> in aodh. >> >> any thoughts ? > > I agree that filtering is probably enough in Aodh use case. > > OTOH, we have support for complex query already merged in, and we can > share the code with Gnocchi (and probably Ceilometer). > > `alarm list' is actually `GET /v2/alarms', which is very REST-y, so I > don't think we should drop it. > shall we drop 'alarm search' nomenclature and use just 'alarm list' for both queries (standard and complex). the concern i have right now is the proposal is to add standard query support to 'alarm list' while complex query support is in 'alarm search'. this is very confusing especially because both commands use '--query' as their option input. cheers, -- gord __ 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] [telemetry][aodh] "aodh alarm list" vs "aodh alarm search"
On Fri, Mar 04 2016, liusheng wrote: > Hi folks, > Currently, we have supported "aodh alarm list" and "aodh alarm search" > commands > to query alarms. They both need mandatory "--type" parameter, and I want to > drop the limitation[1]. if we agree that, the "alarm list" will only used to > list all alarms and don't support any query pamareters, it will be equal to > "alarm search" command without any --query parameter specified. The "alarm > search" command is designed to support complex query which can perform almost > all the filtering query, the complex query has been supportted in Gnocchi. > IRC > meeting disscussions [3]. > > So we don't need two overlapping interfaces and want to drop one, "alarm list" > or "alarm search" ? > > i. The "alarm search" need users to post a expression in JSON format to > perform > spedific query, it is not easy to use and it is unlike a customary practice (I > mean the most common usages of filtering query of other openstack projects), > compare to "alarm list --filter xxx=zzz" usage. > > ii. we don't have a strong requirement to support *complex* query scenarios of > alarms, we only have alarms and alarm history records in aodh. > > iii. I personally think it is enough to support filtering query with > "--filter" > which is easy to implement [2], and, we have plan to support pagination query > in aodh. > > any thoughts ? I agree that filtering is probably enough in Aodh use case. OTOH, we have support for complex query already merged in, and we can share the code with Gnocchi (and probably Ceilometer). `alarm list' is actually `GET /v2/alarms', which is very REST-y, so I don't think we should drop it. Complex search is there, the code should be shared¹ and has a tiny cost on our code base. So is there really a point in dropping it? Gnocchi has exactly the same problem, and I think in the end having both is just good enough. ¹ Doing a oslo.db.complexsearch lib is on my TODO for a while :) -- Julien Danjou // Free Software hacker // https://julien.danjou.info signature.asc Description: PGP signature __ 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] [telemetry][aodh] "aodh alarm list" vs "aodh alarm search"
On Fri, Mar 04, 2016 at 09:57:35AM +0800, liusheng wrote: > Hi folks, > Currently, we have supported "aodh alarm list" and "aodh alarm > search" commands to query alarms. They both need mandatory "--type" > parameter, and I want to drop the limitation[1]. if we agree that, > the "alarm list" will only used to list all alarms and don't > support any query pamareters, it will be equal to "alarm search" > command without any --query parameter specified. The "alarm search" > command is designed to support complex query which can perform > almost all the filtering query, the complex query has been > supportted in Gnocchi. IRC meeting disscussions [3]. > > So we don't need two overlapping interfaces and want to drop one, > "alarm list" or "alarm search" ? > > i. The "alarm search" need users to post a expression in JSON format > to perform spedific query, it is not easy to use and it is unlike a > customary practice (I mean the most common usages of filtering query > of other openstack projects), compare to "alarm list --filter > xxx=zzz" usage. > > ii. we don't have a strong requirement to support *complex* query > scenarios of alarms, we only have alarms and alarm history records > in aodh. > > iii. I personally think it is enough to support filtering query with > "--filter" which is easy to implement [2], and, we have plan to > support pagination query in aodh. +100 Really concerned that some projects keep inventing new things without notion of cross-project guidelines. There have been a consensus to remove individual CLIs [1], "advanced" filtering options [2]. If there is really such a need to do ' resource search', maybe it is not just an aodh thing. Just two cents from a user's perspective. [1] http://specs.openstack.org/openstack/openstack-specs/specs/deprecate-cli.html [2] http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html __ 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] [telemetry][aodh] "aodh alarm list" vs "aodh alarm search"
Hi folks, Currently, we have supported "aodh alarm list" and "aodh alarm search" commands to query alarms. They both need mandatory "--type" parameter, and I want to drop the limitation[1]. if we agree that, the "alarm list" will only used to list all alarms and don't support any query pamareters, it will be equal to "alarm search" command without any --query parameter specified. The "alarm search" command is designed to support complex query which can perform almost all the filtering query, the complex query has been supportted in Gnocchi. IRC meeting disscussions [3]. So we don't need two overlapping interfaces and want to drop one, "alarm list" or "alarm search" ? i. The "alarm search" need users to post a expression in JSON format to perform spedific query, it is not easy to use and it is unlike a customary practice (I mean the most common usages of filtering query of other openstack projects), compare to "alarm list --filter xxx=zzz" usage. ii. we don't have a strong requirement to support *complex* query scenarios of alarms, we only have alarms and alarm history records in aodh. iii. I personally think it is enough to support filtering query with "--filter" which is easy to implement [2], and, we have plan to support pagination query in aodh. any thoughts ? [1] https://review.openstack.org/#/c/283958/ [2] https://review.openstack.org/#/c/283959/ [3] http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2016-03-03.log.html#t2016-03-03T15:21:14 __ 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
