Tuesday, 2013-12-24

openstackgerritZhiQiang Fan proposed a change to openstack/ceilometer: Fix broken i18n support  https://review.openstack.org/6377703:18
*** sayali has joined #openstack-ceilometer05:16
*** sayali has quit IRC05:35
*** sayali has joined #openstack-ceilometer05:38
openstackgerritJenkins proposed a change to openstack/ceilometer: Imported Translations from Transifex  https://review.openstack.org/6280806:04
*** asalkeld has quit IRC06:30
openstackgerritFengqian.gao proposed a change to openstack/ceilometer: Change pagination related methods of mongodb and db2  https://review.openstack.org/4186906:35
openstackgerritFengqian.gao proposed a change to openstack/ceilometer: Add pagination support for sqlalchemy database  https://review.openstack.org/3545406:41
*** sayali has quit IRC06:57
*** sayali has joined #openstack-ceilometer06:58
*** sayali has quit IRC07:05
*** sayali has joined #openstack-ceilometer07:23
*** urulama has joined #openstack-ceilometer07:33
*** boris-42 has quit IRC07:37
*** SergeyLukjanov has joined #openstack-ceilometer07:41
*** sayali_ has joined #openstack-ceilometer07:55
*** sayali has quit IRC07:56
*** ildikov has quit IRC08:20
*** sayali_ has quit IRC08:35
*** sayali has joined #openstack-ceilometer08:45
*** sayali has quit IRC08:49
openstackgerritYuuichi Fujioka proposed a change to openstack/ceilometer: (WIP)Implements monitoring-network-from-opendaylight  https://review.openstack.org/6389008:53
*** sayali has joined #openstack-ceilometer09:08
*** urulama has quit IRC09:19
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: Run unit tests against MySQL  https://review.openstack.org/5948909:42
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: Run tests against PostgreSQL  https://review.openstack.org/6304909:42
*** ruhe has joined #openstack-ceilometer09:52
*** urulama has joined #openstack-ceilometer10:19
*** sayali has quit IRC10:32
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: Run unit tests against MySQL  https://review.openstack.org/5948910:35
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: Run tests against PostgreSQL  https://review.openstack.org/6304910:35
*** ruhe has quit IRC10:39
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: Run unit tests against MySQL  https://review.openstack.org/5948910:47
openstackgerritJulien Danjou proposed a change to openstack/ceilometer: Run tests against PostgreSQL  https://review.openstack.org/6304910:47
*** sayali has joined #openstack-ceilometer10:53
jd__fucking global conf variable, lost hours on that11:07
*** ruhe has joined #openstack-ceilometer11:09
*** urulama has quit IRC11:10
*** boris-42 has joined #openstack-ceilometer11:11
*** sayali has quit IRC11:12
*** sayali has joined #openstack-ceilometer11:33
*** ruhe has quit IRC11:34
*** ruhe has joined #openstack-ceilometer11:36
nprivalova1jd__, ping11:49
jd__nprivalova1: pong11: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
ityaptinjd__ Hi! Blueprint for this  https://blueprints.launchpad.net/ceilometer/+spec/run-all-pollsters-on-demand11:51
ityaptinjd__ 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 uuid11:53
jd__and also change the model11:53
ityaptinjd__ 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 broadcast11:57
jd__no need for a list11:57
nadya_jd__, so it can be done by means of rabbit11:58
jd__nadya_: it should yeah11: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 it12:00
jd__lol12:00
jd__sorry that was the wrong channel12:00
jd__ignore that :)12:00
nadya_jd__, great! I'm afraid of these words. Especially in terms of SQL12:01
*** ruhe has quit IRC12:02
nadya_jd__, thank you, we will start to broadcast :)12:02
jd__cool :)12:04
jd__have fun12:04
*** ruhe has joined #openstack-ceilometer12:04
*** ruhe has quit IRC12:19
openstackgerritZhiQiang Fan proposed a change to openstack/ceilometer: Empty files should no longer contain copyright  https://review.openstack.org/6391212:19
*** ruhe has joined #openstack-ceilometer12:22
*** ruhe has quit IRC12:28
*** ruhe has joined #openstack-ceilometer12:30
*** ruhe has quit IRC12:33
*** ruhe has joined #openstack-ceilometer12:42
*** julienvey has joined #openstack-ceilometer13:43
*** nadya_ has quit IRC13:48
*** nprivalova has joined #openstack-ceilometer13:49
*** jd__` has joined #openstack-ceilometer13:59
*** vrovachev1 has quit IRC14:06
*** nsaje has quit IRC14:06
*** jd__ has quit IRC14:06
*** jd__` is now known as jd__14:06
*** vrovachev1 has joined #openstack-ceilometer14:10
*** nsaje has joined #openstack-ceilometer14:10
*** SergeyLukjanov has quit IRC14:11
*** SergeyLukjanov has joined #openstack-ceilometer14:14
*** ildikov has joined #openstack-ceilometer14:21
*** ruhe is now known as ruhe_14:23
*** ruhe_ has quit IRC14:23
*** ruhe has joined #openstack-ceilometer14:26
*** annegentle_ has quit IRC14:27
*** ruhe is now known as ruhe_14:35
*** ruhe_ has quit IRC14:36
*** ruhe has joined #openstack-ceilometer14:45
*** SergeyLukjanov has quit IRC14:53
*** SergeyLukjanov has joined #openstack-ceilometer14:56
* sayali is away: 14:59
*** boris-42 has quit IRC15:10
*** flwang has quit IRC15:28
*** flwang has joined #openstack-ceilometer15:29
*** sayali has quit IRC15:36
*** sayali has joined #openstack-ceilometer15:37
*** ruhe is now known as ruhe_15:42
*** ruhe has joined #openstack-ceilometer16:07
*** vrovachev1 has left #openstack-ceilometer16:12
*** ruhe has quit IRC16:20
*** boris-42 has joined #openstack-ceilometer16:34
*** prad has joined #openstack-ceilometer16:53
*** prad has quit IRC17:09
*** prad has joined #openstack-ceilometer17:10
*** jaypipes has joined #openstack-ceilometer17:13
jaypipesildikov: 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-ceilometer18:02
*** ruhe has quit IRC18:15
ildikovjaypipes: well, I did not have a choice in case of my workmails :)18:19
jaypipesildikov: :)18:19
jaypipesildikov: makes responding to your posts very difficult!18:20
ildikovjaypipes: after some mails, it is difficult in case of any clients18:20
jaypipeshow so?18:21
jaypipesevolution/mutt/pine/thunderbird all know how to properly indent replies on mailing list posts ;)18:21
ildikovI mean, after a point I do not have patience to follow the ">>>>>>>" signs :)18:21
jaypipesonly outlook seems to fail miserably at it.18:21
jaypipesildikov: ah :) I see...18:21
ildikovI like Thunderbird, in the ancient times in college I've used it much :)18:22
jaypipesildikov: 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
ildikovjaypipes: I've read about rich queries, which are using this approach18:23
jaypipesildikov: the "query" is the HTTP request itself.18:23
jaypipesildikov: could you show me a link please?18:23
ildikovjaypipes: I understand your doubt in this, I will not say that I was familiar with from the first second18:24
ildikovjaypipes: unfortunately I haven't saved the links, but I will look for them again18:24
ildikovjaypipes: 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 reply18:25
jaypipesildikov: 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
ildikovjaypipes: http://okfnlabs.org/blog/2013/07/01/elasticsearch-query-tutorial.html18:28
ildikovjaypipes: As it is not against any currently existing standards, I think we should keep in mind the advantages it have18:30
ildikovjaypipes: I mean, how easy or difficult to use it and how much effort is to maintain the code18:31
* sayali is away: 18:31
jaypipesildikov: it uses GET... curl {endpoint}/_search?q=title:jones&size=5&pretty=true18:33
jaypipesand curl -XGET {endpoint}/_search -d 'Query-as-JSON'18:34
ildikovjaypipes: sorry, I wanted to find one fast :)18:34
jaypipesit does not use POST.... that's what I've been trying to say.18:34
jaypipesildikov: ok :)18:34
ildikovjaypipes: 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 request18:45
jaypipesildikov: I disagree :) long query strings in a URL are common and exactly what the query string parameters were designed for...18:47
jaypipesildikov: we could also base64encode the JSON as a single ?_search= parameter like the elasticsearch API does. I'd be fine with that...18:47
ildikovjaypipes: if you mean the query string in GET by query strings, I cannot see how it could be extended for advanced queries18:55
jaypipesildikov: GET /meters?_query=<BASE64-encoded JSON query>18:56
jaypipesildikov: no need to change the existing API, just adds a custom _query parameter that matches your JSON query language.18:56
ildikovjaypipes: 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 functionalities18:59
ildikovjaypipes: I still do not know how this _query parameter is handled by wsme19:00
ildikovjaypipes: and for stored queries, if we ever reach that point, this solution is a starting point19:01
jaypipesildikov: "query" is not a resource. it's a method. having POST /query not create a resource is not REST.19:04
jaypipesildikov: 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
ildikovjaypipes: /v2/meters/(meter_id)/, what I meant19:07
jaypipesildikov: I'm not following you... what would be the purpose of /v2/meters/{meter_id}?_query?=XXX19:09
*** sayali has quit IRC19:14
ildikovjaypipes: the current API supports to specify a query with an url like this too19:15
jaypipesildikov: nothing I am proposing would change that.19:15
ildikovjaypipes: 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 way19:17
jaypipesildikov: 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
ildikovjaypipes: I mean, to have /meters?_query=<JSON query>,. and /meters?query=<current simple query> and /meters/(meter_id)?query=<current simple query>19:18
jaypipesildikov: 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
jaypipesildikov: you could easily, for instance, do this: GET /meters?q=json:<BASE-64-ENCODED-ADVANCED-QUERY>19:21
ildikovjaypipes: sorry about calling q as query :)19:22
jaypipesno worries, I forgot too :)19:22
ildikovjaypipes: 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 step19:29
ildikovjaypipes: we've already had some issues with wsme too19:30
jaypipesildikov: 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
jaypipesI propose adding one more key, called "advanced" or something...19:31
jaypipeswhich would be a base-64-encoded "advanced query JSON blob"19:31
jaypipeslike you have in your examples.19:31
ildikovjaypipes: oh, I understand now, what your suggestion is19:32
jaypipesildikov: or, you could do something like have an "op" type of "expression", where the value is a SQL-like condition?19:33
ildikovjaypipes: we proposed this grammar as Ceilometer supports both SQL and noSQL DBs19:34
jaypipesildikov: ah, good point...19:35
ildikovjaypipes: I'm still against to expand the current query grammar with the JSON based advanced field19:37
ildikovjaypipes: it seems to be a big mess19:38
ildikovjaypipes: as in that way we would expand a current grammar, with another one, where the advanced one covers the functionalities of the simple query19:40
jaypipesildikov: what about something like this: http://paste.openstack.org/show/56731/19:48
jaypipesildikov: fully backwards compatible, works with both SQL and NoSQL, and uses the existing q= param.19:49
ildikovjaypipes: the current query does not support 'or'19:54
jaypipesildikov: the above paste uses "expr":  <your query language>19:55
jaypipesildikov: you would add the "expr" evaluation...19:55
ildikovjaypipes: do you mean to evaluate the expression as advanced query if there is an "expr" field in the query (q=...)?19:57
jaypipesyes, exactly.19:58
ildikovI'm not familiar with this solution as it is still an embedded query in the query expression20:00
gibihi 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
jaypipesgibi: old way or the new way.20:06
jaypipesgibi: right, not both at same time :)20:06
ildikovjaypipes: I still think that using the same query option in GET against one endpoint with two different query grammars, is not a user friendly solution20:13
gibijaypipes: what is the bigger problem for you, a) we use POST for the query b) having two separate grammar for querying?20:20
gibias 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 confusion20:36
gibiso the question is which confusion is the bigger one20:36
*** ildikov_ has joined #openstack-ceilometer21:10
jaypipesgibi: using POST for the query and having a separate /query resource are both no-no's in my veiew.21:16
jaypipesgibi: 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
gibijaypipes: 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
jaypipesgibi: 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 examples21:22
ildikov_jaypipes: my IE has just died, Microsoft is not with me today ;)21:23
jaypipeshehe :)21:24
gibihere 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 Xmas21:24
jaypipesgibi: :)21:27
jaypipesildikov: 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
jaypipesLOL!21:29
ildikov_jaypipes: ok, probably a bit more about shoes, but this ones is not a problem either :)21:30
jaypipesildikov: are you two in Hungary?21:30
ildikov_jaypipes: yes21:31
gibijaypipes: jep21:32
jaypipesnice.21:32
ildikov_jaypipes: yes, we are a bit workaholics, but it's not serious :)21:36
*** ildikov__ has joined #openstack-ceilometer21:44
*** ildikov_ has quit IRC21:45
ildikov__jaypipes: I sign off for today, it became a bit late here, Merry Christmas :)21:49
jaypipesyou too!22:06
*** jaypipes has quit IRC22:07
*** ildikov__ has quit IRC22:08
*** prad has quit IRC22:21
*** ildikov has quit IRC22:22
*** SergeyLukjanov has quit IRC23:31
*** boris-42 has quit IRC23:44

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!