*** chandan_kumar has joined #openstack-climate | 04:05 | |
*** chandan_kumar has quit IRC | 06:01 | |
*** chandan_kumar has joined #openstack-climate | 06:16 | |
*** chandan_kumar has quit IRC | 06:22 | |
*** chandan_kumar has joined #openstack-climate | 06:40 | |
*** tomek_adamczewsk has joined #openstack-climate | 08:09 | |
*** bauzas has joined #openstack-climate | 08:15 | |
*** chandan_kumar has quit IRC | 09:14 | |
*** chandan_kumar has joined #openstack-climate | 09:15 | |
openstackgerrit | A change was merged to stackforge/climate: V2 API Support for before_end param configuration https://review.openstack.org/89833 | 09:19 |
---|---|---|
openstackgerrit | A change was merged to stackforge/python-climateclient: Handle elapsed_time params in climate client https://review.openstack.org/90759 | 09:19 |
bauzas | ^^ Binge reviewing | 09:20 |
*** tomek_adamczewsk has quit IRC | 09:33 | |
*** tomek_adamczewsk has joined #openstack-climate | 09:35 | |
openstackgerrit | A change was merged to stackforge/climate: API returns project/user/trust ids without dashes https://review.openstack.org/89412 | 09:48 |
*** cmart has joined #openstack-climate | 12:25 | |
*** casanch1 has joined #openstack-climate | 12:25 | |
cmart | Hi casanch1 | 12:29 |
cmart | I saw the changes you made for ClimateClient.. | 12:29 |
cmart | Do you have any idea why Jenkins is failing? | 12:30 |
casanch1 | hey cmart | 12:30 |
casanch1 | nope | 12:30 |
casanch1 | it says that it can't rebase | 12:30 |
casanch1 | but I rebased locally with no problems | 12:30 |
casanch1 | will try again | 12:30 |
cmart | cool! It will be great to have your changes on the v2 client version | 12:31 |
openstackgerrit | Cristian A Sanchez proposed a change to stackforge/python-climateclient: Climate client now shows the list of commands https://review.openstack.org/90393 | 12:36 |
casanch1 | now it worked | 12:41 |
cmart | great! Thanks! | 12:46 |
cmart | DinaBelova, bauzas, are you there? | 12:47 |
DinaBelova | yes | 12:47 |
bauzas | cmart: yes | 12:47 |
cmart | I want to ask you about the climate_url for the v2 client | 12:47 |
DinaBelova | okay, go on) | 12:47 |
DinaBelova | notice that I'm not pinging you) | 12:47 |
DinaBelova | not to ruine your irc client) | 12:48 |
cmart | hahaha! thanks Dina! | 12:48 |
cmart | OK.. So, I saw yesterday that keystone is retrieving a url with this format: "http://{ip}:{port=1234}/v1 | 12:48 |
bauzas | yep ? | 12:48 |
cmart | and the thing is that I was thinking to change that.. | 12:49 |
cmart | the problem here is (hold on).. | 12:49 |
DinaBelova | heh, it's even more interesting - it's {protocol}://{ip}:{port}/v1 | 12:50 |
cmart | in the shell module (https://github.com/stackforge/python-climateclient/blob/master/climateclient/shell.py#L408) | 12:51 |
cmart | we are passing that url to the clients.. | 12:51 |
DinaBelova | without the version - version is passed separately via self.options.os_reservation_api_version | 12:52 |
bauzas | +1 | 12:52 |
DinaBelova | bauzas - +1 to me? :) | 12:52 |
cmart | the 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 |
cmart | but if I change that os_reservation_api_version, the URL won't change | 12:52 |
cmart | from my perspective, the url should not have the version.. | 12:53 |
cmart | and then, in the client.py, I should append the version to the client_path | 12:53 |
DinaBelova | that's interesting thing, yes | 12:53 |
DinaBelova | I got what do you mean | 12:53 |
cmart | I saw other clients, like novaclient | 12:53 |
cmart | and they have a similar situation | 12:54 |
DinaBelova | url is got from the keystone - with the version, as it's the endpoint | 12:54 |
DinaBelova | so to change the url itself you need t hack the *idea* of keystone endoints, what's not really good | 12:54 |
cmart | but they took another path( the one that we got now, with {protocol}://{ip}:{port}/{version} due to backward compatibility | 12:54 |
*** pafuent has joined #openstack-climate | 12:54 | |
cmart | pafuent, we are talking about the thing with the climate_url with the version at the end | 12:55 |
pafuent | cmart: Hi | 12:56 |
DinaBelova | the 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 instance | 12:56 |
cmart | what do u mean with "needed ops"? | 12:58 |
pafuent | DinaBelova: I think I'm not getting something. The two options could point to wrong endpoints if the user wont see the needed ops | 12:58 |
DinaBelova | well, I guess me may get rid of the options.os_reservation_api_version at all | 12:58 |
DinaBelova | and just get the version from the endpoint | 12:59 |
DinaBelova | client version, I mean | 12:59 |
DinaBelova | other projects have problems with it - I guess that's the stuff that was there for quite a long time) | 12:59 |
pafuent | DinaBelova: So the idea is to add the two endpoints in Keystone, and then query the appropriate service type in each client version | 13:00 |
cmart | I think that we have the change to do it right :) but how are we going to handle future versions? | 13:01 |
pafuent | DinaBelova: right? | 13:01 |
DinaBelova | pafuent, usually there is only one endpoint for the project, but I guess your variant is ok))) | 13:01 |
DinaBelova | as currently there are v3 endpoints for the compute, as I remember | 13:01 |
DinaBelova | I'm ok with 2 endpoints and option deciding what endpoint to choose | 13:02 |
pafuent | DinaBelova: Yes, and if blazar gets incubated we will add the Keystone v3 endpoint :-D | 13:02 |
cmart | bauzas: any comments on this? | 13:03 |
DinaBelova | the 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 least | 13:03 |
* bauzas having tons of logs to read | 13:03 | |
pafuent | DinaBelova: I have one concern about using versioned services types | 13:04 |
DinaBelova | pafuent, yes? | 13:04 |
bauzas | cmart: maybe I'm reacting too late, but I can't understand why it's a problem | 13:05 |
pafuent | DinaBelova: If the devop that deploy the cloud not set the type correctly we could have problems | 13:05 |
bauzas | cmart: when looking at the reservation endpoint, we get the url | 13:05 |
bauzas | with version in it | 13:05 |
DinaBelova | pafuent, well.... that's the openstack... it'll be problems anyway :? | 13:05 |
bauzas | so we can instanciate the right client | 13:05 |
DinaBelova | bauzas, +1 | 13:06 |
pafuent | DinaBelova: But if we modify the endpoint adding the version, we will have that under our control | 13:06 |
pafuent | DinaBelova: Is less error prone | 13:06 |
DinaBelova | pafuent, sorry, lost your point | 13:06 |
DinaBelova | what do you propose? | 13:06 |
bauzas | and if a developer wants to use a specific version, then it instanciate the right client using the flag | 13:07 |
cmart | the thing is that changing the flag won't change the url | 13:07 |
cmart | (I think) | 13:07 |
bauzas | test it | 13:07 |
bauzas | sorry, break | 13:08 |
DinaBelova | bauzas, I guess cmart is right here | 13:08 |
DinaBelova | url is from the keystone | 13:08 |
bauzas | one alternative would be to look at /version | 13:08 |
pafuent | DinaBelova: 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 type | 13:08 |
DinaBelova | with the endpoint versiob | 13:08 |
bauzas | sorry , break again | 13:08 |
bauzas | the common use in Openstack for autodiscovery is to add a /version endpoint or at the root | 13:09 |
DinaBelova | pafuent - the problem is that all other projects use versioned url - and they communicate with each other | 13:09 |
DinaBelova | without any flags | 13:09 |
DinaBelova | using only the endpoints | 13:09 |
DinaBelova | so ideally there is keystone giving the endpoint | 13:09 |
DinaBelova | and that's it - for other services/clients not to use flags, etc | 13:10 |
DinaBelova | that was original idea of service catalog | 13:10 |
pafuent | Yes, but their are choosing versions using the service type, which is the same | 13:10 |
DinaBelova | well, service type is compute, reservation - that's normal | 13:10 |
DinaBelova | to get endpoint from "what service you need" | 13:11 |
DinaBelova | but not really normal from the "what version of what service do you need" | 13:11 |
pafuent | IIRC cinder and nova have two endonpoints | 13:12 |
DinaBelova | pafuent, yes - but by default they mught grep the first one in the list, if it does not matter as i remember correctly | 13:12 |
pafuent | Ok | 13:13 |
DinaBelova | or there is default one - if there are two of them | 13:13 |
DinaBelova | that's not really nice, I quite agree with you | 13:13 |
DinaBelova | but | 13:13 |
DinaBelova | if we want to continue this discussion | 13:13 |
pafuent | Is the OS way of doing | 13:13 |
DinaBelova | we need other feedback here too | 13:13 |
cmart | :) | 13:13 |
DinaBelova | pafuent, yes - you may send the letter to the ML | 13:13 |
DinaBelova | and start this discussion | 13:14 |
DinaBelova | I guess it'll be quite interesting one | 13:14 |
cmart | short term solution? | 13:14 |
cmart | I mean, so I can move on? | 13:14 |
cmart | :D | 13:14 |
pafuent | Ok, I'll do | 13:14 |
cmart | Climate_url.endwith(os_reservation_api_version) then use "client"? | 13:14 |
DinaBelova | cmart, please use idea of multiple endpoint defined by the flag now | 13:14 |
DinaBelova | cmart - well, or this variant | 13:15 |
DinaBelova | :) | 13:15 |
cmart | os_reservation_api_version = "the flag" ? | 13:15 |
DinaBelova | yes | 13:15 |
cmart | OK | 13:15 |
cmart | I will do it like that.. | 13:15 |
cmart | I have a meeting and I have to go.. | 13:16 |
cmart | thanks for the feedback | 13:16 |
DinaBelova | cmart, see you) | 13:17 |
openstackgerrit | Sylvain Bauza proposed a change to stackforge/climate: Create Statuses objects for Leases https://review.openstack.org/90755 | 14:28 |
*** bauzas has quit IRC | 15:07 | |
*** bauzas has joined #openstack-climate | 15:07 | |
*** tomek_adamczewsk has quit IRC | 15:12 | |
*** tomek_adamczewsk has joined #openstack-climate | 15:21 | |
*** tomek_adamczewsk has quit IRC | 15:40 | |
*** bauzas has quit IRC | 15:59 | |
*** chandan_kumar has quit IRC | 16:19 | |
*** cmart has quit IRC | 16:20 | |
*** pafuent has quit IRC | 17:17 | |
*** chandan_kumar has joined #openstack-climate | 17:20 | |
*** cmart has joined #openstack-climate | 17:21 | |
*** openstackgerrit has quit IRC | 17:32 | |
*** pafuent has joined #openstack-climate | 17:33 | |
*** openstackgerrit has joined #openstack-climate | 17:33 | |
*** chandan_kumar has quit IRC | 17:49 | |
*** pafuent has quit IRC | 18:53 | |
*** pafuent has joined #openstack-climate | 19:04 | |
*** tomek_adamczewsk has joined #openstack-climate | 19:06 | |
openstackgerrit | Cristian A Sanchez proposed a change to stackforge/python-climateclient: Add the option defer-by to postpone start_date https://review.openstack.org/91148 | 19:48 |
*** tomek_adamczewsk has quit IRC | 19:50 | |
*** tomek_adamczewsk has joined #openstack-climate | 20:00 | |
*** tomek_adamczewsk has quit IRC | 20:14 | |
*** cmart has quit IRC | 20:50 | |
openstackgerrit | Cristian A Sanchez proposed a change to stackforge/python-climateclient: Add the option defer-by to postpone start_date https://review.openstack.org/91148 | 20:58 |
*** tomek_adamczewsk has joined #openstack-climate | 21:01 | |
*** pafuent has left #openstack-climate | 21:16 | |
*** casanch1_ has joined #openstack-climate | 21:19 | |
*** casanch1 has quit IRC | 21:22 | |
*** casanch1_ has quit IRC | 21:24 | |
*** tomek_adamczewsk has quit IRC | 21:49 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!