Tuesday, 2014-04-29

*** chandan_kumar has joined #openstack-climate04:05
*** chandan_kumar has quit IRC06:01
*** chandan_kumar has joined #openstack-climate06:16
*** chandan_kumar has quit IRC06:22
*** chandan_kumar has joined #openstack-climate06:40
*** tomek_adamczewsk has joined #openstack-climate08:09
*** bauzas has joined #openstack-climate08:15
*** chandan_kumar has quit IRC09:14
*** chandan_kumar has joined #openstack-climate09:15
openstackgerritA change was merged to stackforge/climate: V2 API Support for before_end param configuration  https://review.openstack.org/8983309:19
openstackgerritA change was merged to stackforge/python-climateclient: Handle elapsed_time params in climate client  https://review.openstack.org/9075909:19
bauzas^^ Binge reviewing09:20
*** tomek_adamczewsk has quit IRC09:33
*** tomek_adamczewsk has joined #openstack-climate09:35
openstackgerritA change was merged to stackforge/climate: API returns project/user/trust ids without dashes  https://review.openstack.org/8941209:48
*** cmart has joined #openstack-climate12:25
*** casanch1 has joined #openstack-climate12:25
cmartHi casanch112:29
cmartI saw the changes you made for ClimateClient..12:29
cmartDo you have any idea why Jenkins is failing?12:30
casanch1hey cmart12:30
casanch1nope12:30
casanch1it says that it can't rebase12:30
casanch1but I rebased locally with no problems12:30
casanch1will try again12:30
cmartcool! It will be great to have your changes on the v2 client version12:31
openstackgerritCristian A Sanchez proposed a change to stackforge/python-climateclient: Climate client now shows the list of commands  https://review.openstack.org/9039312:36
casanch1now it worked12:41
cmartgreat! Thanks!12:46
cmartDinaBelova, bauzas, are you there?12:47
DinaBelovayes12:47
bauzascmart: yes12:47
cmartI want to ask you about the climate_url for the v2 client12:47
DinaBelovaokay, go on)12:47
DinaBelovanotice that I'm not pinging you)12:47
DinaBelovanot to ruine your irc client)12:48
cmarthahaha! thanks Dina!12:48
cmartOK.. So, I saw yesterday that keystone is retrieving a url with this format: "http://{ip}:{port=1234}/v112:48
bauzasyep ?12:48
cmartand the thing is that I was thinking to change that..12:49
cmartthe problem here is (hold on)..12:49
DinaBelovaheh, it's even more interesting - it's {protocol}://{ip}:{port}/v112:50
cmartin the shell module (https://github.com/stackforge/python-climateclient/blob/master/climateclient/shell.py#L408)12:51
cmartwe are passing that url to the clients..12:51
DinaBelovawithout the version - version is passed separately via self.options.os_reservation_api_version12:52
bauzas+112:52
DinaBelovabauzas - +1 to me? :)12:52
cmartthe clients are "deciding" which client version  is needed based in the options.os_reservation_api_version (https://github.com/stackforge/python-climateclient/blob/master/climateclient/client.py#L27)12:52
cmartbut if I change that os_reservation_api_version, the URL won't change12:52
cmartfrom my perspective, the url should not have the version..12:53
cmartand then, in the client.py, I should append the version to the client_path12:53
DinaBelovathat's interesting thing, yes12:53
DinaBelovaI got what do you mean12:53
cmartI saw other clients, like novaclient12:53
cmartand they have a similar situation12:54
DinaBelovaurl is got from the keystone - with the version, as it's the endpoint12:54
DinaBelovaso to change the url itself you need t hack the *idea* of keystone endoints, what's not really good12:54
cmartbut they took another path( the one that we got now, with {protocol}://{ip}:{port}/{version} due to backward compatibility12:54
*** pafuent has joined #openstack-climate12:54
cmartpafuent, we are talking about the thing with the climate_url with the version at the end12:55
pafuentcmart: Hi12:56
DinaBelovathe solution is dirty, but well - get endpoint from the keystone, but use the client due to the options.os_reservation_api_version  - if user won't see needed ops, that means it's wrong endpoint in the keystone. Or it's the other variant - change the ending of the endpoint due to the options.os_reservation_api_version - as Nova does for the keystone, fo instance12:56
cmartwhat do u mean with "needed ops"?12:58
pafuentDinaBelova: I think I'm not getting something. The two options could point to wrong endpoints if the user wont see the needed ops12:58
DinaBelovawell, I guess me may get rid of the options.os_reservation_api_version  at all12:58
DinaBelovaand just get the version from the endpoint12:59
DinaBelovaclient version, I mean12:59
DinaBelovaother projects have problems with it - I guess that's the stuff that was there for quite a long time)12:59
pafuentDinaBelova: So the idea is to add the two endpoints in Keystone, and then query the appropriate service type in each client version13:00
cmartI think that we have the change to do it right :) but how are we going to handle future versions?13:01
pafuentDinaBelova: right?13:01
DinaBelovapafuent, usually there is only one endpoint for the project, but I guess your variant is ok)))13:01
DinaBelovaas currently there are v3 endpoints for the compute, as I remember13:01
DinaBelovaI'm ok with 2 endpoints and option deciding what endpoint to choose13:02
pafuentDinaBelova: Yes, and if blazar gets incubated we will add the Keystone v3 endpoint :-D13:02
cmartbauzas: any comments on this?13:03
DinaBelovathe only moment here is that there might be somehow one endpoint there - I guess it'll be the cool to have warning "no endpoints %s found" and use the only one left - and if there will be 404 for some request - it'll be warning at least13:03
* bauzas having tons of logs to read13:03
pafuentDinaBelova: I have one concern about using versioned services types13:04
DinaBelovapafuent, yes?13:04
bauzascmart: maybe I'm reacting too late, but I can't understand why it's a problem13:05
pafuentDinaBelova: If the devop that deploy the cloud not set the type correctly we could have problems13:05
bauzascmart: when looking at the reservation endpoint, we get the url13:05
bauzaswith version in it13:05
DinaBelovapafuent, well.... that's the openstack... it'll be problems anyway :?13:05
bauzasso we can instanciate the right client13:05
DinaBelovabauzas, +113:06
pafuentDinaBelova: But if we modify the endpoint adding the version, we will have that under our control13:06
pafuentDinaBelova: Is less error prone13:06
DinaBelovapafuent, sorry, lost your point13:06
DinaBelovawhat do you propose?13:06
bauzasand if a developer wants to use a specific version, then it instanciate the right client using the flag13:07
cmartthe thing is that changing the flag won't change the url13:07
cmart(I think)13:07
bauzastest it13:07
bauzassorry, break13:08
DinaBelovabauzas, I guess cmart is right here13:08
DinaBelovaurl is from the keystone13:08
bauzasone alternative would be to look at /version13:08
pafuentDinaBelova: If we get the unversioned url, we will know always how to add the version, but we don't know how the devop wrote the version in the service type13:08
DinaBelovawith the endpoint versiob13:08
bauzassorry , break again13:08
bauzasthe common use in Openstack for autodiscovery is to add a /version endpoint or at the root13:09
DinaBelovapafuent - the problem is that all other projects use versioned url - and they communicate with each other13:09
DinaBelovawithout any flags13:09
DinaBelovausing only the endpoints13:09
DinaBelovaso ideally there is keystone giving the endpoint13:09
DinaBelovaand that's it - for other services/clients not to use flags, etc13:10
DinaBelovathat was original idea of service catalog13:10
pafuentYes, but their are choosing versions using the service type, which is the same13:10
DinaBelovawell, service type is compute, reservation - that's normal13:10
DinaBelovato get endpoint from "what service you need"13:11
DinaBelovabut not really normal from the "what version of what service do you need"13:11
pafuentIIRC cinder and nova have two endonpoints13:12
DinaBelovapafuent, yes - but by default they mught grep the first one in the list, if it does not matter as i remember correctly13:12
pafuentOk13:13
DinaBelovaor there is default one - if there are two of them13:13
DinaBelovathat's not really nice, I quite agree with you13:13
DinaBelovabut13:13
DinaBelovaif we want to continue this discussion13:13
pafuentIs the OS way of doing13:13
DinaBelovawe need other  feedback here too13:13
cmart:)13:13
DinaBelovapafuent, yes - you may send the letter to the ML13:13
DinaBelovaand start this discussion13:14
DinaBelovaI guess it'll be quite interesting one13:14
cmartshort term solution?13:14
cmartI mean, so I can move on?13:14
cmart:D13:14
pafuentOk, I'll do13:14
cmartClimate_url.endwith(os_reservation_api_version) then use "client"?13:14
DinaBelovacmart, please use idea of multiple endpoint defined by the flag now13:14
DinaBelovacmart - well, or this variant13:15
DinaBelova:)13:15
cmartos_reservation_api_version = "the flag" ?13:15
DinaBelovayes13:15
cmartOK13:15
cmartI will do it like that..13:15
cmartI have a meeting and I have to go..13:16
cmartthanks for the feedback13:16
DinaBelovacmart, see you)13:17
openstackgerritSylvain Bauza proposed a change to stackforge/climate: Create Statuses objects for Leases  https://review.openstack.org/9075514:28
*** bauzas has quit IRC15:07
*** bauzas has joined #openstack-climate15:07
*** tomek_adamczewsk has quit IRC15:12
*** tomek_adamczewsk has joined #openstack-climate15:21
*** tomek_adamczewsk has quit IRC15:40
*** bauzas has quit IRC15:59
*** chandan_kumar has quit IRC16:19
*** cmart has quit IRC16:20
*** pafuent has quit IRC17:17
*** chandan_kumar has joined #openstack-climate17:20
*** cmart has joined #openstack-climate17:21
*** openstackgerrit has quit IRC17:32
*** pafuent has joined #openstack-climate17:33
*** openstackgerrit has joined #openstack-climate17:33
*** chandan_kumar has quit IRC17:49
*** pafuent has quit IRC18:53
*** pafuent has joined #openstack-climate19:04
*** tomek_adamczewsk has joined #openstack-climate19:06
openstackgerritCristian A Sanchez proposed a change to stackforge/python-climateclient: Add the option defer-by to postpone start_date  https://review.openstack.org/9114819:48
*** tomek_adamczewsk has quit IRC19:50
*** tomek_adamczewsk has joined #openstack-climate20:00
*** tomek_adamczewsk has quit IRC20:14
*** cmart has quit IRC20:50
openstackgerritCristian A Sanchez proposed a change to stackforge/python-climateclient: Add the option defer-by to postpone start_date  https://review.openstack.org/9114820:58
*** tomek_adamczewsk has joined #openstack-climate21:01
*** pafuent has left #openstack-climate21:16
*** casanch1_ has joined #openstack-climate21:19
*** casanch1 has quit IRC21:22
*** casanch1_ has quit IRC21:24
*** tomek_adamczewsk has quit IRC21:49

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