openstackgerrit | ZhiQiang Fan proposed a change to openstack/ceilometer: Fix broken i18n support https://review.openstack.org/63777 | 03:18 |
---|---|---|
*** sayali has joined #openstack-ceilometer | 05:16 | |
*** sayali has quit IRC | 05:35 | |
*** sayali has joined #openstack-ceilometer | 05:38 | |
openstackgerrit | Jenkins proposed a change to openstack/ceilometer: Imported Translations from Transifex https://review.openstack.org/62808 | 06:04 |
*** asalkeld has quit IRC | 06:30 | |
openstackgerrit | Fengqian.gao proposed a change to openstack/ceilometer: Change pagination related methods of mongodb and db2 https://review.openstack.org/41869 | 06:35 |
openstackgerrit | Fengqian.gao proposed a change to openstack/ceilometer: Add pagination support for sqlalchemy database https://review.openstack.org/35454 | 06:41 |
*** sayali has quit IRC | 06:57 | |
*** sayali has joined #openstack-ceilometer | 06:58 | |
*** sayali has quit IRC | 07:05 | |
*** sayali has joined #openstack-ceilometer | 07:23 | |
*** urulama has joined #openstack-ceilometer | 07:33 | |
*** boris-42 has quit IRC | 07:37 | |
*** SergeyLukjanov has joined #openstack-ceilometer | 07:41 | |
*** sayali_ has joined #openstack-ceilometer | 07:55 | |
*** sayali has quit IRC | 07:56 | |
*** ildikov has quit IRC | 08:20 | |
*** sayali_ has quit IRC | 08:35 | |
*** sayali has joined #openstack-ceilometer | 08:45 | |
*** sayali has quit IRC | 08:49 | |
openstackgerrit | Yuuichi Fujioka proposed a change to openstack/ceilometer: (WIP)Implements monitoring-network-from-opendaylight https://review.openstack.org/63890 | 08:53 |
*** sayali has joined #openstack-ceilometer | 09:08 | |
*** urulama has quit IRC | 09:19 | |
openstackgerrit | Julien Danjou proposed a change to openstack/ceilometer: Run unit tests against MySQL https://review.openstack.org/59489 | 09:42 |
openstackgerrit | Julien Danjou proposed a change to openstack/ceilometer: Run tests against PostgreSQL https://review.openstack.org/63049 | 09:42 |
*** ruhe has joined #openstack-ceilometer | 09:52 | |
*** urulama has joined #openstack-ceilometer | 10:19 | |
*** sayali has quit IRC | 10:32 | |
openstackgerrit | Julien Danjou proposed a change to openstack/ceilometer: Run unit tests against MySQL https://review.openstack.org/59489 | 10:35 |
openstackgerrit | Julien Danjou proposed a change to openstack/ceilometer: Run tests against PostgreSQL https://review.openstack.org/63049 | 10:35 |
*** ruhe has quit IRC | 10:39 | |
openstackgerrit | Julien Danjou proposed a change to openstack/ceilometer: Run unit tests against MySQL https://review.openstack.org/59489 | 10:47 |
openstackgerrit | Julien Danjou proposed a change to openstack/ceilometer: Run tests against PostgreSQL https://review.openstack.org/63049 | 10:47 |
*** sayali has joined #openstack-ceilometer | 10:53 | |
jd__ | fucking global conf variable, lost hours on that | 11:07 |
*** ruhe has joined #openstack-ceilometer | 11:09 | |
*** urulama has quit IRC | 11:10 | |
*** boris-42 has joined #openstack-ceilometer | 11:11 | |
*** sayali has quit IRC | 11:12 | |
*** sayali has joined #openstack-ceilometer | 11:33 | |
*** ruhe has quit IRC | 11:34 | |
*** ruhe has joined #openstack-ceilometer | 11:36 | |
nprivalova1 | jd__, ping | 11:49 |
jd__ | nprivalova1: pong | 11:49 |
*** nprivalova1 is now known as nadya_ | 11:49 | |
nadya_ | jd__, we have several questions about running pollsters on demand. I thought it would be easier :) | 11:50 |
jd__ | shoot :) | 11:50 |
ityaptin | jd__ Hi! Blueprint for this https://blueprints.launchpad.net/ceilometer/+spec/run-all-pollsters-on-demand | 11:51 |
ityaptin | jd__ I think we can call function 'poll_and_publish' in AgentManager with rpc, but we have to store list of all running agents on instances. | 11:52 |
jd__ | why do you have to store a list of running agent? | 11:53 |
jd__ | so you need a migration script to add a uniqueness to that uuid | 11:53 |
jd__ | and also change the model | 11:53 |
ityaptin | jd__ about list - it's need for us because we don't know addresses of remote instances with running agents. As example our high load test with 100 compute nodes. | 11:56 |
nadya_ | as I understand, we need a way to notify all agents that "we want you to start polling" | 11:57 |
jd__ | nadya_: sure, but you just need to register them on RPC I'd say and do some sort of broadcast | 11:57 |
jd__ | no need for a list | 11:57 |
nadya_ | jd__, so it can be done by means of rabbit | 11:58 |
jd__ | nadya_: it should yeah | 11:58 |
jd__ | should I say via oslo RPC or messaging :) | 11:59 |
nadya_ | jd__, and why did you say about migrations and models? I didn't get it | 12:00 |
jd__ | lol | 12:00 |
jd__ | sorry that was the wrong channel | 12:00 |
jd__ | ignore that :) | 12:00 |
nadya_ | jd__, great! I'm afraid of these words. Especially in terms of SQL | 12:01 |
*** ruhe has quit IRC | 12:02 | |
nadya_ | jd__, thank you, we will start to broadcast :) | 12:02 |
jd__ | cool :) | 12:04 |
jd__ | have fun | 12:04 |
*** ruhe has joined #openstack-ceilometer | 12:04 | |
*** ruhe has quit IRC | 12:19 | |
openstackgerrit | ZhiQiang Fan proposed a change to openstack/ceilometer: Empty files should no longer contain copyright https://review.openstack.org/63912 | 12:19 |
*** ruhe has joined #openstack-ceilometer | 12:22 | |
*** ruhe has quit IRC | 12:28 | |
*** ruhe has joined #openstack-ceilometer | 12:30 | |
*** ruhe has quit IRC | 12:33 | |
*** ruhe has joined #openstack-ceilometer | 12:42 | |
*** julienvey has joined #openstack-ceilometer | 13:43 | |
*** nadya_ has quit IRC | 13:48 | |
*** nprivalova has joined #openstack-ceilometer | 13:49 | |
*** jd__` has joined #openstack-ceilometer | 13:59 | |
*** vrovachev1 has quit IRC | 14:06 | |
*** nsaje has quit IRC | 14:06 | |
*** jd__ has quit IRC | 14:06 | |
*** jd__` is now known as jd__ | 14:06 | |
*** vrovachev1 has joined #openstack-ceilometer | 14:10 | |
*** nsaje has joined #openstack-ceilometer | 14:10 | |
*** SergeyLukjanov has quit IRC | 14:11 | |
*** SergeyLukjanov has joined #openstack-ceilometer | 14:14 | |
*** ildikov has joined #openstack-ceilometer | 14:21 | |
*** ruhe is now known as ruhe_ | 14:23 | |
*** ruhe_ has quit IRC | 14:23 | |
*** ruhe has joined #openstack-ceilometer | 14:26 | |
*** annegentle_ has quit IRC | 14:27 | |
*** ruhe is now known as ruhe_ | 14:35 | |
*** ruhe_ has quit IRC | 14:36 | |
*** ruhe has joined #openstack-ceilometer | 14:45 | |
*** SergeyLukjanov has quit IRC | 14:53 | |
*** SergeyLukjanov has joined #openstack-ceilometer | 14:56 | |
* sayali is away: | 14:59 | |
*** boris-42 has quit IRC | 15:10 | |
*** flwang has quit IRC | 15:28 | |
*** flwang has joined #openstack-ceilometer | 15:29 | |
*** sayali has quit IRC | 15:36 | |
*** sayali has joined #openstack-ceilometer | 15:37 | |
*** ruhe is now known as ruhe_ | 15:42 | |
*** ruhe has joined #openstack-ceilometer | 16:07 | |
*** vrovachev1 has left #openstack-ceilometer | 16:12 | |
*** ruhe has quit IRC | 16:20 | |
*** boris-42 has joined #openstack-ceilometer | 16:34 | |
*** prad has joined #openstack-ceilometer | 16:53 | |
*** prad has quit IRC | 17:09 | |
*** prad has joined #openstack-ceilometer | 17:10 | |
*** jaypipes has joined #openstack-ceilometer | 17:13 | |
jaypipes | ildikov: I gather you use Microsoft Outlook for your mailing list mail? ;) | 17:14 |
* sayali is back (gone 02:04:32) | 17:41 | |
*** ruhe has joined #openstack-ceilometer | 18:02 | |
*** ruhe has quit IRC | 18:15 | |
ildikov | jaypipes: well, I did not have a choice in case of my workmails :) | 18:19 |
jaypipes | ildikov: :) | 18:19 |
jaypipes | ildikov: makes responding to your posts very difficult! | 18:20 |
ildikov | jaypipes: after some mails, it is difficult in case of any clients | 18:20 |
jaypipes | how so? | 18:21 |
jaypipes | evolution/mutt/pine/thunderbird all know how to properly indent replies on mailing list posts ;) | 18:21 |
ildikov | I mean, after a point I do not have patience to follow the ">>>>>>>" signs :) | 18:21 |
jaypipes | only outlook seems to fail miserably at it. | 18:21 |
jaypipes | ildikov: ah :) I see... | 18:21 |
ildikov | I like Thunderbird, in the ancient times in college I've used it much :) | 18:22 |
jaypipes | ildikov: so, I still have an issue with naming the resource "query"... because a POST is intended to create a resource. In the case of your proposed API, there is nothing created. | 18:22 |
ildikov | jaypipes: I've read about rich queries, which are using this approach | 18:23 |
jaypipes | ildikov: the "query" is the HTTP request itself. | 18:23 |
jaypipes | ildikov: could you show me a link please? | 18:23 |
ildikov | jaypipes: I understand your doubt in this, I will not say that I was familiar with from the first second | 18:24 |
ildikov | jaypipes: unfortunately I haven't saved the links, but I will look for them again | 18:24 |
ildikov | jaypipes: I know that this approach is not the common one, but there are so many reasons, we are using this, as I mentioned in my reply | 18:25 |
jaypipes | ildikov: I understand the reasons. I just don't believe it is a common practice, and it goes against pretty much all other OpenStack API practices, which is why I'm hesitant. I definitely see the use cases, though I believe that a saved reports/ resource is more appropriate for this type of thing. | 18:27 |
ildikov | jaypipes: http://okfnlabs.org/blog/2013/07/01/elasticsearch-query-tutorial.html | 18:28 |
ildikov | jaypipes: As it is not against any currently existing standards, I think we should keep in mind the advantages it have | 18:30 |
ildikov | jaypipes: I mean, how easy or difficult to use it and how much effort is to maintain the code | 18:31 |
* sayali is away: | 18:31 | |
jaypipes | ildikov: it uses GET... curl {endpoint}/_search?q=title:jones&size=5&pretty=true | 18:33 |
jaypipes | and curl -XGET {endpoint}/_search -d 'Query-as-JSON' | 18:34 |
ildikov | jaypipes: sorry, I wanted to find one fast :) | 18:34 |
jaypipes | it does not use POST.... that's what I've been trying to say. | 18:34 |
jaypipes | ildikov: ok :) | 18:34 |
ildikov | jaypipes: it seems to use the request body as an option, which still not seems to be a common solution, and I'm also not sure that a long query should be sent in the URL of the request | 18:45 |
jaypipes | ildikov: I disagree :) long query strings in a URL are common and exactly what the query string parameters were designed for... | 18:47 |
jaypipes | ildikov: we could also base64encode the JSON as a single ?_search= parameter like the elasticsearch API does. I'd be fine with that... | 18:47 |
ildikov | jaypipes: if you mean the query string in GET by query strings, I cannot see how it could be extended for advanced queries | 18:55 |
jaypipes | ildikov: GET /meters?_query=<BASE64-encoded JSON query> | 18:56 |
jaypipes | ildikov: no need to change the existing API, just adds a custom _query parameter that matches your JSON query language. | 18:56 |
ildikov | jaypipes: as for the current API, probably it would be still better to have a resource defined for query, as the current api support query after specifying a meter in the request url, etc, which will be a mess if we combine the simple nd complex query functionalities | 18:59 |
ildikov | jaypipes: I still do not know how this _query parameter is handled by wsme | 19:00 |
ildikov | jaypipes: and for stored queries, if we ever reach that point, this solution is a starting point | 19:01 |
jaypipes | ildikov: "query" is not a resource. it's a method. having POST /query not create a resource is not REST. | 19:04 |
jaypipes | ildikov: could you elaborate on "as the current api support query after specifying a meter in the request url"? I'm not quite sure what you mean... | 19:05 |
ildikov | jaypipes: /v2/meters/(meter_id)/, what I meant | 19:07 |
jaypipes | ildikov: I'm not following you... what would be the purpose of /v2/meters/{meter_id}?_query?=XXX | 19:09 |
*** sayali has quit IRC | 19:14 | |
ildikov | jaypipes: the current API supports to specify a query with an url like this too | 19:15 |
jaypipes | ildikov: nothing I am proposing would change that. | 19:15 |
ildikov | jaypipes: I understand that, but to introduce an advanced query functionality with _query sign in the current endpoint structure does not seem to be a clear way | 19:17 |
jaypipes | ildikov: sure it does... it's the most common and well understood searching/querying methodology on the Internet. See Google's search, Yahoo's, elasticsearch, etc... | 19:18 |
ildikov | jaypipes: I mean, to have /meters?_query=<JSON query>,. and /meters?query=<current simple query> and /meters/(meter_id)?query=<current simple query> | 19:18 |
jaypipes | ildikov: well, first of all, it's q=, not query= :) And I would think that expanding the use of the existing q= parameter is the best solution... | 19:20 |
jaypipes | ildikov: you could easily, for instance, do this: GET /meters?q=json:<BASE-64-ENCODED-ADVANCED-QUERY> | 19:21 |
ildikov | jaypipes: sorry about calling q as query :) | 19:22 |
jaypipes | no worries, I forgot too :) | 19:22 |
ildikov | jaypipes: I would like to have a more or less clean structure at the end and it would be also good to have a backward compatible solution too, so I'm not sure that it would be a good idea to change the current implementation to a JSON-based advanced query in one step | 19:29 |
ildikov | jaypipes: we've already had some issues with wsme too | 19:30 |
jaypipes | ildikov: not change... make an addition to. the current q param structure is like so: | 19:30 |
jaypipes | { | 19:30 |
jaypipes | "field": "resource_id", | 19:30 |
jaypipes | "op": "eq", | 19:30 |
jaypipes | "type": "string", | 19:30 |
jaypipes | "value": "bd9431c1-8d69-4ad3-803a-8d4a6b89fd36" | 19:30 |
jaypipes | } | 19:30 |
jaypipes | I propose adding one more key, called "advanced" or something... | 19:31 |
jaypipes | which would be a base-64-encoded "advanced query JSON blob" | 19:31 |
jaypipes | like you have in your examples. | 19:31 |
ildikov | jaypipes: oh, I understand now, what your suggestion is | 19:32 |
jaypipes | ildikov: or, you could do something like have an "op" type of "expression", where the value is a SQL-like condition? | 19:33 |
ildikov | jaypipes: we proposed this grammar as Ceilometer supports both SQL and noSQL DBs | 19:34 |
jaypipes | ildikov: ah, good point... | 19:35 |
ildikov | jaypipes: I'm still against to expand the current query grammar with the JSON based advanced field | 19:37 |
ildikov | jaypipes: it seems to be a big mess | 19:38 |
ildikov | jaypipes: as in that way we would expand a current grammar, with another one, where the advanced one covers the functionalities of the simple query | 19:40 |
jaypipes | ildikov: what about something like this: http://paste.openstack.org/show/56731/ | 19:48 |
jaypipes | ildikov: fully backwards compatible, works with both SQL and NoSQL, and uses the existing q= param. | 19:49 |
ildikov | jaypipes: the current query does not support 'or' | 19:54 |
jaypipes | ildikov: the above paste uses "expr": <your query language> | 19:55 |
jaypipes | ildikov: you would add the "expr" evaluation... | 19:55 |
ildikov | jaypipes: do you mean to evaluate the expression as advanced query if there is an "expr" field in the query (q=...)? | 19:57 |
jaypipes | yes, exactly. | 19:58 |
ildikov | I'm not familiar with this solution as it is still an embedded query in the query expression | 20:00 |
gibi | hi jaypipes, ildikov. I read your discussion. jaypipes: do you suggest to allow both the current and the new way of querying in the same GET request, or it is ok to say the user either use the old way or the new way in one request but not both int the same? | 20:05 |
jaypipes | gibi: old way or the new way. | 20:06 |
jaypipes | gibi: right, not both at same time :) | 20:06 |
ildikov | jaypipes: I still think that using the same query option in GET against one endpoint with two different query grammars, is not a user friendly solution | 20:13 |
gibi | jaypipes: what is the bigger problem for you, a) we use POST for the query b) having two separate grammar for querying? | 20:20 |
gibi | as I see we might missues the POST for querying and that can cause confusion, what you suggest is to give two different possibilities for the user in one url for querying which I think can also cause confusion | 20:36 |
gibi | so the question is which confusion is the bigger one | 20:36 |
*** ildikov_ has joined #openstack-ceilometer | 21:10 | |
jaypipes | gibi: using POST for the query and having a separate /query resource are both no-no's in my veiew. | 21:16 |
jaypipes | gibi: but I do see your and ildikov's point... what I will do is write another ML post that shows examples for my proposal, and we'll go from there. | 21:17 |
gibi | jaypipes: thanks for the effort. I agree to continue on the ML with examples that way we might get comments from others as well. | 21:21 |
jaypipes | gibi: sounds good :) probably will do it thursday (off for Xmas soon) | 21:22 |
ildikov_ | jaypipes: that would be great to continue on the ML with some examples | 21:22 |
ildikov_ | jaypipes: my IE has just died, Microsoft is not with me today ;) | 21:23 |
jaypipes | hehe :) | 21:24 |
gibi | here Xmas is already ongoing so I agree to continue afterwards. :) | 21:24 |
ildikov_ | jaypipes: thanks for the comments and the effort in the last minutes before Xmas | 21:24 |
jaypipes | gibi: :) | 21:27 |
jaypipes | ildikov: no worries! i can talk forever about this stuff... :) | 21:28 |
ildikov_ | jaypipes: I'm a woman, I can talk forever about nearly anything ;) | 21:29 |
jaypipes | LOL! | 21:29 |
ildikov_ | jaypipes: ok, probably a bit more about shoes, but this ones is not a problem either :) | 21:30 |
jaypipes | ildikov: are you two in Hungary? | 21:30 |
ildikov_ | jaypipes: yes | 21:31 |
gibi | jaypipes: jep | 21:32 |
jaypipes | nice. | 21:32 |
ildikov_ | jaypipes: yes, we are a bit workaholics, but it's not serious :) | 21:36 |
*** ildikov__ has joined #openstack-ceilometer | 21:44 | |
*** ildikov_ has quit IRC | 21:45 | |
ildikov__ | jaypipes: I sign off for today, it became a bit late here, Merry Christmas :) | 21:49 |
jaypipes | you too! | 22:06 |
*** jaypipes has quit IRC | 22:07 | |
*** ildikov__ has quit IRC | 22:08 | |
*** prad has quit IRC | 22:21 | |
*** ildikov has quit IRC | 22:22 | |
*** SergeyLukjanov has quit IRC | 23:31 | |
*** boris-42 has quit IRC | 23:44 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!