| *** saju_m has joined #openstack-climate | 05:08 | |
| *** saju_m has quit IRC | 06:18 | |
| *** DinaBelova_ is now known as DinaBelova | 06:26 | |
| openstackgerrit | A change was merged to stackforge/python-climateclient: Support not-json error responses https://review.openstack.org/71328 | 07:08 |
|---|---|---|
| *** saju_m has joined #openstack-climate | 07:32 | |
| *** DinaBelova is now known as DinaBelova_ | 07:44 | |
| *** bauzas has joined #openstack-climate | 07:48 | |
| *** bauzas has quit IRC | 08:31 | |
| *** DinaBelova_ is now known as DinaBelova | 08:57 | |
| *** bauzas has joined #openstack-climate | 09:07 | |
| *** DinaBelova is now known as DinaBelova_ | 09:09 | |
| *** f_rossigneux has joined #openstack-climate | 09:11 | |
| *** DinaBelova_ is now known as DinaBelova | 09:27 | |
| *** YorikSar has joined #openstack-climate | 09:51 | |
| *** saju_m has quit IRC | 09:58 | |
| *** DinaBelova is now known as DinaBelova_ | 10:57 | |
| *** DinaBelova_ is now known as DinaBelova | 10:59 | |
| *** pafuent has joined #openstack-climate | 12:20 | |
| pafuent | Good morning (at least for me) | 12:34 |
| SergeyLukjanov | pafuent, o/ | 12:35 |
| pafuent | DinaBelova: Are you around? I need to ask something about your comment regarding the date format | 12:38 |
| *** DinaBelova is now known as DinaBelova_ | 12:44 | |
| bauzas | pafuent: | 12:44 |
| pafuent | bauzas: Yes? | 12:45 |
| bauzas | pafuent: indeed, that's something we need to discuss | 12:45 |
| bauzas | pafuent: I think that should be configurable | 12:45 |
| bauzas | pafuent: I saw Dina's comment | 12:45 |
| pafuent | bauzas: Sorry I didn't read your last name | 12:45 |
| bauzas | pafuent: no pb | 12:46 |
| bauzas | pafuent: I was ooo these last days | 12:46 |
| bauzas | pafuent: so, regarding your patch, that needs to be discussed with DinaBelova_ | 12:46 |
| pafuent | bauzas: If the client has a config file, I could add the same option to that file | 12:47 |
| bauzas | pafuent: I would even propose to translate the datetime into something less readable in the API | 12:48 |
| bauzas | pafuent: so that would only be something clear on the CLI side | 12:48 |
| pafuent | bauzas: Why? (Here is too early, my brain is still sleep) | 12:49 |
| pafuent | bauzas: BTW, I think that the sync between client and API would be easy, because the API exception contains the date format. So if a climate client user don't have access to the climate API server, he/she could config the format correctly reading the exception text | 12:53 |
| bauzas | pafuent: sorry, was still focusing on my other patch | 12:53 |
| pafuent | bauzas: NP | 12:54 |
| bauzas | pafuent: let's wait DinaBelova_ to come back | 12:54 |
| bauzas | pafuent: because I agree with you | 12:54 |
| bauzas | pafuent: but the main issue is the sync in between API and CLI conf options | 12:54 |
| pafuent | bauzas: Ok | 12:55 |
| bauzas | pafuent: so, that's why I'm proposing to expose thru the API a pure datestring | 12:55 |
| bauzas | pafuent: not formatted | 12:55 |
| bauzas | pafuent: and build it on a clear way only by the CLI | 12:55 |
| bauzas | so, that would only require a confflag on the CLI side | 12:55 |
| bauzas | pafuent: I'm currently focusing on the API side because I'm delivering the Pecan/WSME port | 12:56 |
| bauzas | pafuent: and that's why I think the API should not be that verbose | 12:56 |
| bauzas | pafuent: only the CLI should do the changes | 12:56 |
| pafuent | bauzas: So, the idea is to use the standard date format of python in API (without an specific format) and put something more human in the client | 12:57 |
| bauzas | pafuent: exactly | 12:57 |
| bauzas | pafuent: but that requires a change on the client side | 12:57 |
| bauzas | pafuent: so we just need to ensure it would be backwards compatible | 12:58 |
| *** DinaBelova_ is now known as DinaBelova | 13:11 | |
| DinaBelova | I'm here | 13:12 |
| DinaBelova | bauzas, pafuent, hello :) | 13:12 |
| DinaBelova | I was having late dinner :) | 13:12 |
| DinaBelova | really I'm ok with standard '2014-02-07 17:14:16.558204' passing through REST API | 13:15 |
| DinaBelova | and some more human friendly client version | 13:15 |
| bauzas | DinaBelova: that involves that dates are passed to the API on a Python version | 13:17 |
| bauzas | s/version/standard | 13:17 |
| bauzas | when creating or updating a lease | 13:17 |
| DinaBelova | mmm | 13:17 |
| DinaBelova | sorry | 13:17 |
| DinaBelova | can't get pi\oint | 13:17 |
| DinaBelova | point* | 13:17 |
| bauzas | DinaBelova: we could still keep the old format for backwards compatibility | 13:17 |
| bauzas | (14:15:26) DinaBelova: really I'm ok with standard '2014-02-07 17:14:16.558204' passing through REST API | 13:18 |
| bauzas | that's not only for showing dates | 13:18 |
| DinaBelova | yep, sure | 13:18 |
| bauzas | that should also impact how dates are sent to the API | 13:18 |
| bauzas | the change should manage both formats | 13:18 |
| DinaBelova | I mean use standard str(datetime.datetime) via all rest | 13:18 |
| bauzas | DinaBelova: I'm just thinking of the upgrade path :) | 13:19 |
| DinaBelova | or backword compatibility is ok too | 13:19 |
| bauzas | as we delivered our first release :) | 13:19 |
| DinaBelova | :) | 13:19 |
| DinaBelova | I think that old format is quite nice speaking about lease creation | 13:19 |
| DinaBelova | for user not to be worried about all these little values | 13:20 |
| bauzas | the thing is, we need both if we decide the standard output is standard datetime in Python :) | 13:20 |
| DinaBelova | yep | 13:20 |
| bauzas | DinaBelova: yes, but there is non sense to produce a readable API | 13:20 |
| bauzas | the API should just be able to handle both formats, that's it :) | 13:21 |
| bauzas | but for printing, it should print the standard format | 13:21 |
| DinaBelova | as I said I'm ok with that :) | 13:21 |
| bauzas | but that requires a patch to the client and a patch to climate: ) | 13:21 |
| DinaBelova | okay :) | 13:21 |
| DinaBelova | why not :) | 13:21 |
| bauzas | seems like the client needs to be updated first | 13:22 |
| bauzas | DinaBelova: you got my idea ? | 13:22 |
| bauzas | because if we update the API, it will break the client | 13:22 |
| DinaBelova | sure, I got it | 13:22 |
| bauzas | welcome to the loving world of production :) | 13:23 |
| DinaBelova | bauzas, I got it quite time ago :D I think we were speaking about same thing for a while :D | 13:23 |
| DinaBelova | I've got big problems with climate devstack, btw | 13:24 |
| DinaBelova | :( | 13:24 |
| DinaBelova | I was testing it today, but it's not about climate problems now | 13:24 |
| DinaBelova | I still could not install keystone deps | 13:24 |
| DinaBelova | with devstack | 13:25 |
| pafuent | DinaBelova: bauzas: I'm back | 13:55 |
| DinaBelova | :) | 13:55 |
| pafuent | DinaBelova: bauzas: To recap, first I should make a patch in the client adding a config file with the date format | 13:56 |
| pafuent | DinaBelova: bauzas: Then, I should modify the actual API patch to support standard python date format and the actual date format | 13:56 |
| pafuent | DinaBelova: bauzas: Ok? | 13:57 |
| bauzas | pafuent: not only the patch should have a confflag, but should also be able to receive values as datestring | 13:57 |
| bauzas | pafuent:but from now on , it should post using the previous date format | 13:58 |
| pafuent | bauzas: Ok, the API will sent responses with the standard date format | 13:58 |
| bauzas | nah | 13:58 |
| bauzas | pafuent: lemme explain you the scenario : | 13:58 |
| bauzas | 1. upgrade client with 2 confflags : | 13:58 |
| DinaBelova | bauzas, please, explain your idea | 13:58 |
| bauzas | dateformat | 13:59 |
| bauzas | hold on | 14:00 |
| bauzas | I'm suddently having a meeting | 14:00 |
| bauzas | so, the idea is : | 14:00 |
| pafuent | bauzas: Ok | 14:00 |
| DinaBelova | the only thing I can't get is if other openstack clients use any config options | 14:00 |
| bauzas | DinaBelova: well, you're right | 14:00 |
| DinaBelova | as far as I remember that's not a common practice | 14:01 |
| bauzas | so the client should be able to manage both formats | 14:03 |
| bauzas | and a new release of client should then send new format | 14:03 |
| bauzas | once the API is upgraded | 14:03 |
| bauzas | I'm leaving, meeting :/ | 14:04 |
| pafuent | bauzas: Bye | 14:04 |
| DinaBelova | maybe it'll be better to add standard datetime support for climate itself (both with old variant)? and then rewrite client to use it? and new version of client will send new format, as old one won't | 14:05 |
| DinaBelova | I just mean that config option for client is strange | 14:05 |
| pafuent | DinaBelova: I'm feeling a little dizzy :) | 14:06 |
| DinaBelova | me too | 14:06 |
| DinaBelova | that's argument without real need | 14:06 |
| DinaBelova | flag is useless thing - it should be one format rest api knows about | 14:06 |
| DinaBelova | and client will support it | 14:06 |
| pafuent | DinaBelova: 1-Update API to support both format (backward compatibility) | 14:06 |
| DinaBelova | it was a good idea for the first look | 14:07 |
| DinaBelova | but now it seems strange for me | 14:07 |
| pafuent | DinaBelova: 2-Update client to sent to the API the standard format, but use the old one to show dates and for the parameters | 14:07 |
| pafuent | DinaBelova: Are you ok with this two steps? | 14:08 |
| DinaBelova | pafuent, I'm just going crazy trying to understand how that backward compatibility will look here | 14:08 |
| DinaBelova | it's useful if it'll be old client? | 14:08 |
| DinaBelova | if so - yes, it's needed | 14:08 |
| DinaBelova | and that's good idea | 14:09 |
| DinaBelova | and in this case these steps are ok | 14:09 |
| DinaBelova | if I messed you - I'm ok with these steps :) | 14:10 |
| DinaBelova | i'm just thinking and writing my thoughts, sorry :) | 14:10 |
| pafuent | DinaBelova: Yeah, the code to support the two formats will be ugly | 14:10 |
| DinaBelova | :( | 14:10 |
| DinaBelova | yep | 14:11 |
| DinaBelova | maybe, that might be done as new API version for Climate with new format | 14:11 |
| DinaBelova | and in this case it'll be about endpoints | 14:11 |
| DinaBelova | like v1 - use old vormat | 14:11 |
| DinaBelova | v2 - use new | 14:11 |
| DinaBelova | if so, it''s looking ok | 14:12 |
| pafuent | DinaBelova: That's true | 14:12 |
| pafuent | DinaBelova: There is some bp for that? Someone is working on that? | 14:12 |
| DinaBelova | Sylvain is doing api v2 for climate using pecan+wsme | 14:12 |
| pafuent | DinaBelova: Ahhh | 14:13 |
| DinaBelova | I think we may ask him to integrate new date format to it too | 14:13 |
| DinaBelova | when he'll come back | 14:13 |
| DinaBelova | in this case it's ok for me - the only moment here is that date transforming will be done on api level | 14:13 |
| DinaBelova | so manager will get standard view of datetime | 14:13 |
| DinaBelova | I think that'll be nice | 14:14 |
| DinaBelova | and with backward compatibility | 14:14 |
| pafuent | DinaBelova: Yeap | 14:14 |
| DinaBelova | pafuent, ok, agreed :) let's wait Sylvain :) | 14:14 |
| *** casanch1 has joined #openstack-climate | 14:15 | |
| pafuent | DinaBelova: BTW, I'll fix some of your comments in the patch, and upload a new one. At least to clean up a little the patch. | 14:16 |
| DinaBelova | ok, great! | 14:16 |
| pafuent | DinaBelova: Another thing. I think you added some reviewers to https://review.openstack.org/#/c/71614/ | 14:17 |
| pafuent | DinaBelova: Are core reviewers? | 14:17 |
| DinaBelova | I've added infra guys to review | 14:17 |
| DinaBelova | I mean infra core team | 14:17 |
| DinaBelova | But they are quite busy | 14:17 |
| DinaBelova | so review process may take time | 14:17 |
| pafuent | DinaBelova: Ok, thanks. I think OS will make me more patient. | 14:18 |
| DinaBelova | We may try to find mordred in IRC | 14:18 |
| DinaBelova | But I dunno if it will help much | 14:18 |
| DinaBelova | they have mu-u-uch to do :) | 14:18 |
| openstackgerrit | Pablo Andres Fuente proposed a change to stackforge/climate: lease_create now raises InvalidDate exception https://review.openstack.org/71631 | 14:19 |
| DinaBelova | good :) | 14:20 |
| DinaBelova | pafuent, I'm going crazy with that devstack patch | 14:25 |
| DinaBelova | was it working good on your env? | 14:25 |
| pafuent | DinaBelova: Yeap | 14:26 |
| casanch1 | DinaBelova: I tried that patch in my clean devstack installation and worked ok | 14:26 |
| DinaBelova | argh | 14:26 |
| DinaBelova | ;( | 14:26 |
| DinaBelova | my new clean VM + this patch to devstack | 14:26 |
| DinaBelova | don't want to collaborate | 14:26 |
| DinaBelova | I'll recreate all env I think | 14:26 |
| pafuent | DinaBelova: Why? Which is the error? | 14:27 |
| DinaBelova | although I dunno what might go wrong now :( | 14:27 |
| DinaBelova | I've posted some comments to that patch | 14:27 |
| DinaBelova | but the idea is - keystone is not starting' | 14:27 |
| DinaBelova | simply | 14:27 |
| DinaBelova | I had no chance to see if climate is working | 14:27 |
| DinaBelova | cause I have no keystone :( | 14:27 |
| DinaBelova | cause all its reqs were not installed | 14:28 |
| DinaBelova | and so far and so on | 14:28 |
| DinaBelova | wothout clear reasons | 14:28 |
| DinaBelova | without* | 14:28 |
| pafuent | DinaBelova: Yes, it's strange | 14:29 |
| DinaBelova | ok, I'll create new VM - let's see what's it about | 14:30 |
| *** casanch1_ has joined #openstack-climate | 14:33 | |
| *** casanch1 has quit IRC | 14:33 | |
| *** pafuent has quit IRC | 14:33 | |
| *** casanch1_ is now known as casanch1 | 14:33 | |
| *** pafuent has joined #openstack-climate | 14:52 | |
| DinaBelova | meeting in 5 mins on #openstack-meeting :) | 14:56 |
| DinaBelova | casanch1, bauzas, swann, f_rossigneux, SergeyLukjanov, pafuent ^^^ | 14:57 |
| DinaBelova | fooooolks :) | 15:02 |
| DinaBelova | why I see only Cristian on meeting? :) | 15:02 |
| *** pafuent has quit IRC | 15:05 | |
| *** pafuent has joined #openstack-climate | 15:05 | |
| f_rossigneux | Sorry Dina but I am busy this afternoon. | 15:11 |
| DinaBelova | ok | 15:14 |
| bauzas | DinaBelova: sorry, I'm currently in an unattended meeting | 15:22 |
| DinaBelova | bauzas, ok, this meeting will be like some state one | 15:23 |
| *** Nikolay_St has joined #openstack-climate | 15:32 | |
| *** Nikolay_St has quit IRC | 15:38 | |
| DinaBelova | wow, exactly needed time :) | 16:00 |
| DinaBelova | nah, guys | 16:06 |
| DinaBelova | :( | 16:06 |
| DinaBelova | devstack is not working for me | 16:06 |
| DinaBelova | ;( | 16:06 |
| DinaBelova | clean Ubuntu server 12.04 + devstack + climate_devstack != smth working for me now | 16:07 |
| DinaBelova | I dunno if it's somehow my local stuff | 16:07 |
| DinaBelova | or not | 16:07 |
| DinaBelova | bauzas, btw, please read our with pafuent discussion about new date format | 16:07 |
| DinaBelova | it was after you went to your first meeting | 16:08 |
| bauzas | sorry, it was a totally unexpected meeting | 16:08 |
| bauzas | (15:13:05) DinaBelova: I think we may ask him to integrate new date format to it too | 16:09 |
| bauzas | that's the point ? | 16:09 |
| DinaBelova | yes | 16:09 |
| bauzas | I'm OK with it | 16:10 |
| bauzas | that's only matter of patching | 16:10 |
| bauzas | I'll publish tonight a public version of the patch | 16:10 |
| pafuent | Ok | 16:10 |
| bauzas | I'm putting this point as TODO | 16:10 |
| bauzas | let's be clear, I will remove use of strptime | 16:11 |
| bauzas | and print direct datetime | 16:11 |
| bauzas | I'll only accept both strftime using the previous syntax or a native datetime as input | 16:11 |
| bauzas | you all agree ? | 16:12 |
| pafuent | IIRC we talk with DinaBelova about to support only the standard datetime for v2 and use v1 as backward compatibility, right DinaBelova? | 16:13 |
| DinaBelova | pafuent, yep | 16:14 |
| DinaBelova | I suppose that will look much nices | 16:14 |
| DinaBelova | nicer* | 16:14 |
| pafuent | bauzas: Are you ok with this? | 16:14 |
| DinaBelova | pafuent, I found reason for non workingdevstack, btw | 16:14 |
| DinaBelova | :) | 16:14 |
| DinaBelova | new version of WSME has been released | 16:14 |
| DinaBelova | and everything stops working | 16:14 |
| DinaBelova | Could not install requirement ipaddr (from WSME>=0.5b6->keystone==2014.1.dev173.g1923a3f) because of HTTP error HTTP Error 403: Forbidden for URL https://googledrive.com/host/0Bwh63zyus-UlZ1dxQ08zczVRbXc/ipaddr-2.1.11.tar.gz (from http://code.google.com/p/ipaddr-py/) | 16:14 |
| DinaBelova | 0_0 | 16:14 |
| bauzas | yey, there was a thread on it | 16:15 |
| DinaBelova | what the f.ck is that google drive url?????\ | 16:15 |
| DinaBelova | argh | 16:15 |
| DinaBelova | so no dependencies were downloaded | 16:15 |
| DinaBelova | and nothing to install | 16:15 |
| bauzas | DinaBelova: pafuent: IIRC, you ask me to only accept native datetime for v2 as input and ouptut ? | 16:15 |
| bauzas | DinaBelova: pafuent: ok, will do | 16:16 |
| DinaBelova | bauzas, yep | 16:16 |
| bauzas | DinaBelova: pafuent: will remove all code related to strptime/strftime | 16:16 |
| DinaBelova | cause that will look more native | 16:16 |
| DinaBelova | ok | 16:16 |
| DinaBelova | so it should look like | 16:16 |
| DinaBelova | v1 -> transform in API v1 od format to new one and continue to code without strptime/strftime | 16:17 |
| DinaBelova | v2 -> just pass to code without strptime/strftime | 16:17 |
| DinaBelova | smth like that | 16:17 |
| bauzas | ok with it | 16:17 |
| DinaBelova | in this case that will look in OS style - like new args format in new API version | 16:17 |
| bauzas | API v2 will change a little bit | 16:19 |
| bauzas | I tried to stick things as much as possible | 16:19 |
| DinaBelova | I think it's ok | 16:19 |
| bauzas | but that's really hard to keep same outputs | 16:19 |
| DinaBelova | and quite normal | 16:20 |
| DinaBelova | to go further | 16:20 |
| bauzas | the main difference is that the result of a call won't be a dict of dict | 16:20 |
| bauzas | but only a dict | 16:20 |
| bauzas | ie. not { 'lease': {} } but only {} | 16:20 |
| bauzas | the error management also changed | 16:21 |
| DinaBelova | bauzas, please be aware here to pass everything to client back as it wants to parse | 16:21 |
| DinaBelova | I mean that dicts | 16:21 |
| bauzas | that's the issue :) | 16:21 |
| bauzas | I can't :( | 16:21 |
| bauzas | client needs to be patched for V2 | 16:21 |
| DinaBelova | mmm | 16:22 |
| bauzas | that's WSME awesomeness | 16:22 |
| DinaBelova | mmm | 16:23 |
| DinaBelova | I'm not sure if it was before dict of dict | 16:23 |
| DinaBelova | was it? | 16:23 |
| DinaBelova | as I remember now we have just dict returned to client | 16:23 |
| DinaBelova | cause somewhere deep in climate we return dict['lease'] | 16:23 |
| DinaBelova | am I wrong? | 16:23 |
| DinaBelova | I just remember I firstly used in client smth like format(data[lease]) | 16:25 |
| DinaBelova | and then it turned out | 16:25 |
| DinaBelova | that data is already with lease info | 16:26 |
| pafuent | DinaBelova: bauzas: Ok, I'll modify the actual patch: 1) move the date parsing to API v1, 2) remove the use of strptime/strftime in manager | 16:26 |
| *** bauzas has quit IRC | 16:26 | |
| DinaBelova | pafuent, as I understood he'll do that himself: | 16:27 |
| DinaBelova | [20:16:22] <bauzas> DinaBelova: pafuent: will remove all code related to strptime/strftime | 16:27 |
| DinaBelova | nah? | 16:27 |
| pafuent | DinaBelova: Sorry I'm lost | 16:27 |
| DinaBelova | :) | 16:27 |
| DinaBelova | Please don't worry | 16:27 |
| DinaBelova | :) | 16:27 |
| DinaBelova | as for your change request | 16:28 |
| DinaBelova | I think we'll merge it as is | 16:28 |
| DinaBelova | and then Sylvain will rebase on it | 16:28 |
| DinaBelova | and just use | 16:28 |
| DinaBelova | we'll ask him when he'll come back | 16:28 |
| pafuent | DinaBelova: Ok | 16:29 |
| *** ppetit has quit IRC | 16:40 | |
| pafuent | I think isn't okay to raise a NotAuthorized (HTTP 403) exception if the start_date of a lease is before the current time. IMHO an HTTP 400 is more appropriate. Should I report a bug? | 16:41 |
| *** YorikSar has quit IRC | 16:43 | |
| DinaBelova | +1 | 16:44 |
| pafuent | My bad, the HTTP 403 is ok, the name of the exception is misleading | 16:57 |
| pafuent | From RFC2616 | 16:57 |
| pafuent | I'll ask for help to Tolkien | 16:57 |
| pafuent | 10.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status | 16:58 |
| DinaBelova | pafuent, ;) | 17:01 |
| DinaBelova | ok, if 403 is ok - great :) | 17:02 |
| *** casanch1 has left #openstack-climate | 17:02 | |
| pafuent | DinaBelova: I'll change the exception and the message, but I'll use the same status code | 17:04 |
| DinaBelova | pafuent, ok | 17:04 |
| *** DinaBelova is now known as DinaBelova_ | 17:09 | |
| *** bauzas has joined #openstack-climate | 17:28 | |
| bauzas | sorry, had to go | 17:28 |
| bauzas | the best way is for you to compare the APIs once I will release the patch | 17:29 |
| *** YorikSar has joined #openstack-climate | 17:56 | |
| *** bauzas has quit IRC | 18:15 | |
| *** DinaBelova_ is now known as DinaBelova | 19:06 | |
| *** DinaBelova is now known as DinaBelova_ | 20:18 | |
| *** DinaBelova_ is now known as DinaBelova | 20:20 | |
| *** openstackgerrit has quit IRC | 20:34 | |
| *** openstackgerrit has joined #openstack-climate | 20:34 | |
| *** DinaBelova is now known as DinaBelova_ | 21:19 | |
| *** pafuent has left #openstack-climate | 21:23 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!