| *** saju_m has joined #openstack-climate | 06:31 | |
| *** chandankumar_ has quit IRC | 06:45 | |
| *** chandan_kumar has joined #openstack-climate | 06:51 | |
| *** chandan_kumar has quit IRC | 06:55 | |
| *** YorikSar has joined #openstack-climate | 07:00 | |
| *** YorikSar has quit IRC | 07:36 | |
| *** YorikSar has joined #openstack-climate | 07:37 | |
| *** YorikSar has quit IRC | 07:41 | |
| *** YorikSar has joined #openstack-climate | 07:42 | |
| *** bauzas has joined #openstack-climate | 08:15 | |
| *** saju_m has quit IRC | 08:40 | |
| *** saju_m has joined #openstack-climate | 08:43 | |
| *** saju_m has quit IRC | 09:02 | |
| *** chandan_kumar has joined #openstack-climate | 09:03 | |
| openstackgerrit | A change was merged to stackforge/climate: Enable verbose logging in devstack https://review.openstack.org/77114 | 09:21 |
|---|---|---|
| openstackgerrit | A change was merged to stackforge/climate: Adding/Handling DB specific exceptions https://review.openstack.org/74751 | 09:24 |
| *** saju_m has joined #openstack-climate | 09:34 | |
| bauzas | YorikSar: DinaBelova: I got a question about XML support in API | 09:51 |
| bauzas | DinaBelova: there is a thread about deprecating XML in Openstack APIs | 09:52 |
| bauzas | DinaBelova: do you agree with this ? | 09:52 |
| bauzas | DinaBelova: YorikSar: my concern is about https://review.openstack.org/#/c/71011/6/climate/api/v2/middleware/parsable_error.py | 09:52 |
| bauzas | DinaBelova: YorikSar: L71 | 09:52 |
| bauzas | DinaBelova: YorikSar: I'm doing some post-parsing support for XML rendering | 09:52 |
| bauzas | DinaBelova: YorikSar: if we say we won't support XML, I could just place a statement saying to use JSON | 09:53 |
| DinaBelova | bauzas, \o | 09:53 |
| bauzas | DinaBelova: YorikSar: but that's only for errors | 09:53 |
| bauzas | DinaBelova: YorikSar: as WSME supports natively both formats | 09:53 |
| bauzas | DinaBelova: \o | 09:54 |
| bauzas | DinaBelova: YorikSar: or I can provide a Pecan hook for deprecating XML | 09:54 |
| bauzas | DinaBelova: what do you feel about it ? | 09:54 |
| DinaBelova | first of all, I now have no clear idea if I'm ok or not with XML api deprecation :) | 09:55 |
| bauzas | DinaBelova: there was a TC decision to deprecate XML | 09:55 |
| DinaBelova | I'm reading this thread now | 09:55 |
| DinaBelova | ah, yes | 09:55 |
| bauzas | so the YorikSar's comment is worth it | 09:55 |
| DinaBelova | ok, probably some hook for deprecating is ok, but really we need YorikSar to also agree with that :) | 09:56 |
| DinaBelova | let's wait for him :) | 09:56 |
| bauzas | YorikSar: ? :) | 09:56 |
| bauzas | well, the Pecan hook would just say like 'NotImplemented' | 09:56 |
| bauzas | as it's a new API :) | 09:57 |
| DinaBelova | yes, I also think that | 09:57 |
| bauzas | ok, while waiting YorikSar feedback, working on other things | 09:57 |
| DinaBelova | +1 | 09:58 |
| DinaBelova | I'm preparing answer to Joe in mailing thread :) | 09:59 |
| bauzas | yup, saw it | 09:59 |
| YorikSar | bauzas, DinaBelova: Hello, guys :) | 10:09 |
| YorikSar | bauzas: I think, there's nothing to deprecate since there's no Climate API v2 yet. | 10:09 |
| DinaBelova | YorikSar, 'guys' is usually used for mail audience :) | 10:09 |
| DinaBelova | I'm girl :) | 10:09 |
| DinaBelova | so use 'folks' | 10:09 |
| DinaBelova | :) | 10:09 |
| YorikSar | DinaBelova: Oh, you're my buddy anyway ;P | 10:10 |
| DinaBelova | :D | 10:10 |
| bauzas | what's up, peer ? ;-) :D | 10:10 |
| bauzas | YorikSar: I got your point about XML | 10:11 |
| bauzas | YorikSar: API v1 was supporting XML | 10:11 |
| YorikSar | bauzas: So we can just say that v2 doesn't support XML and that's it. We might want to cut XML support out of v1... But I don't think there is support for XML there. | 10:11 |
| bauzas | YorikSar: ok, so we need to force a hook to deny XML then | 10:11 |
| bauzas | YorikSar: do you agree with it ? | 10:12 |
| YorikSar | bauzas: You mean, finter out calls with explicit Accept: application/xml header? | 10:12 |
| YorikSar | *filter | 10:12 |
| bauzas | YorikSar: that would be a Pecan hook with a before() processing, where requests having this header would be returned as non-valid, yes | 10:13 |
| bauzas | YorikSar: if we leave as it is, XML support is there | 10:14 |
| YorikSar | bauzas: Hm... I think, we can invert this logic: pass only requests that have "Accept: application/json" or no "Accept:" header at all. | 10:14 |
| bauzas | well, ok, that's matter of having a glass with either half-empty or half-full :) | 10:15 |
| bauzas | YorikSar: but taking your comment :) | 10:15 |
| YorikSar | bauzas: In fact, I think that even if XML requests won't be denied it won't harm us. Just some undocumented unsupported functionality. | 10:15 |
| bauzas | ok, implementing it, and getting rid of that if branch | 10:15 |
| bauzas | YorikSar: DinaBelova: what do you think about it ? | 10:16 |
| bauzas | DinaBelova: unsupport XML support for responses with 200/300 codes | 10:16 |
| bauzas | DinaBelova: and non-supported rendering layouts for >400 error codes | 10:16 |
| bauzas | that means I can just get rid of the if branch , without doing anything | 10:17 |
| DinaBelova | I think it's ok - I mean we do not ensure XML support, we ensure json | 10:23 |
| DinaBelova | if XML is working that's great, but we don't give any guaranties | 10:23 |
| *** saju_m has quit IRC | 10:25 | |
| bauzas | DinaBelova: ok | 10:26 |
| *** saju_m has joined #openstack-climate | 10:42 | |
| *** saju_m has quit IRC | 11:11 | |
| *** saju_m has joined #openstack-climate | 11:25 | |
| *** jd__ has left #openstack-climate | 12:44 | |
| *** chandan_kumar has quit IRC | 12:48 | |
| *** chandan_kumar has joined #openstack-climate | 12:49 | |
| *** saju_m has quit IRC | 12:52 | |
| *** chandankumar_ has joined #openstack-climate | 12:54 | |
| *** chandan_kumar has quit IRC | 12:57 | |
| *** chandan_kumar has joined #openstack-climate | 15:42 | |
| *** chandan_kumar has quit IRC | 16:03 | |
| *** chandan_kumar has joined #openstack-climate | 16:16 | |
| *** bauzas has quit IRC | 16:57 | |
| *** chandan_kumar has quit IRC | 17:25 | |
| *** bauzas has joined #openstack-climate | 17:34 | |
| *** jogo has joined #openstack-climate | 18:39 | |
| jogo | o/ | 18:42 |
| DinaBelova | jogo, \o | 18:48 |
| DinaBelova | bauzas, btw, you're here? | 18:48 |
| bauzas | DinaBelova: yup, I'm here :) | 18:49 |
| DinaBelova | It looks like our European time zone is nothing for us :D | 18:49 |
| DinaBelova | Once I notices, that it was 2 AM for me, and somehow I did not want to sleep communicating with our Intel folks :D | 18:50 |
| jogo | DinaBelova: this is Joe Gordon | 18:50 |
| jogo | so perhaps I am missing something | 18:50 |
| DinaBelova | jogo, ok, so may you say, what moments are suspicious for you? | 18:51 |
| DinaBelova | maybe that's some kind of misunderstanding between us :) | 18:51 |
| jogo | In its current state. I don't see how Climate can guarantee that an instance will be available, and allow that resource to be used in the interam. | 18:51 |
| DinaBelova | currently we've taken resources for VM from common pool by creating it and giving it shelved state - we've taken resources from compute node instance is running on | 18:53 |
| DinaBelova | our first idea, frankly speaking, was about some special state for Vm in Nova DB | 18:53 |
| DinaBelova | without real VM created | 18:53 |
| jogo | so amazon can do this because they can delete a class of VMs at will (spot instances) | 18:53 |
| jogo | without that concept I don't see how you can do this | 18:54 |
| DinaBelova | but that was not really good idea - 'cause we needed to have much changes in Nova | 18:54 |
| DinaBelova | m-m-m | 18:55 |
| DinaBelova | probably I can't get your point clearly | 18:55 |
| bauzas | jogo: I discussed that point with phil | 18:55 |
| bauzas | jogo: he wanted to propose some implementation of spot instances | 18:56 |
| DinaBelova | oh, I got it | 18:56 |
| DinaBelova | jogo, it was really good mailing thread about that | 18:56 |
| jogo | bauzas: that would be cool but without spot instances I don't see the point | 18:56 |
| bauzas | jogo: yey | 18:56 |
| bauzas | jogo: I agree with the fact that spot instances can be implemented on the Nova side | 18:57 |
| bauzas | jogo: the idea is not to implement features from Nova | 18:57 |
| bauzas | jogo: but only provide some way to schedule them | 18:57 |
| jogo | bauzas: without spot instances I don't see the point of climate | 18:57 |
| DinaBelova | jogo, that's why we have current view of Climate | 18:57 |
| DinaBelova | jogo, we have not only instances ;) | 18:58 |
| bauzas | jogo: why do we need spot instances for this ? | 18:58 |
| bauzas | jogo: that can be a contract about starting an instance on a best-effort mode | 18:58 |
| jogo | bauzas: so my understanding is: lets say my cloud has resources for 10 VMs | 18:58 |
| jogo | I reserve 3 for a week from now, and now my cloud only has space for 7 instances. | 18:59 |
| jogo | bauzas: we have that today, nova boot is best effort | 18:59 |
| jogo | no need to have somethign else | 18:59 |
| DinaBelova | jogo, if we speak about immediate reservations - yes, it looks so | 19:00 |
| DinaBelova | but we're working on different lease concepts | 19:00 |
| DinaBelova | as said on our wiki | 19:00 |
| jogo | with spot instances, I now have a class of VMs that I can delete to make space | 19:00 |
| jogo | DinaBelova: I don't follow what is differnt | 19:00 |
| bauzas | jogo: maybe it's unclear that Climate boots instances later than when asked | 19:00 |
| jogo | why can't i just make a cron job to do 'nova boot' | 19:00 |
| jogo | bauzas: that part is clear, but i don't see the point | 19:01 |
| jogo | sleep 2.days ; nova boot | 19:01 |
| jogo | or cron job | 19:01 |
| jogo | etc | 19:01 |
| bauzas | jogo: agree with this point | 19:01 |
| jogo | or teach heat about that | 19:01 |
| bauzas | jogo: but how are you sure that the boot will succeed in 2 days ? | 19:01 |
| DinaBelova | jogo, probably there will be not enough space in your cloud | 19:02 |
| DinaBelova | if you'll use cron | 19:02 |
| jogo | bauzas: I am not sure | 19:02 |
| jogo | but with the current version of climate your just doing nova boot ; nova shelve; nova boot | 19:02 |
| jogo | or whatever it is | 19:02 |
| jogo | can't heat / cron etc do that | 19:02 |
| DinaBelova | jogo, currently it looks so for VMs, yes | 19:03 |
| jogo | when shelved I an still consuming a space on my cloud | 19:03 |
| DinaBelova | but heat/cron won't do that for more compex use cases | 19:03 |
| jogo | so lets ignore insances for now | 19:03 |
| DinaBelova | with guarantees, different notifications, etc. | 19:03 |
| jogo | how do you want a reservation for a volume to work? | 19:03 |
| jogo | DinaBelova: and Ican just do a sleep 30; heat stack start | 19:04 |
| jogo | etc | 19:04 |
| bauzas | jogo: at the moment, the idea would be to do as for compute nodes | 19:04 |
| bauzas | provided we consider cinder-volumes as dedicated to Climate | 19:04 |
| bauzas | jogo: the idea would be to keep track of the requests | 19:05 |
| bauzas | jogo: and only allocate the volumes when needed | 19:05 |
| DinaBelova | jogo, and frankly speaking smth like that should be node for instances too | 19:05 |
| DinaBelova | but that's difficult question that needs to be discussed | 19:06 |
| DinaBelova | idea of Climate is to give time management opportunity - and of course, current version definitely should be improved | 19:07 |
| DinaBelova | but we're working on it, and will continue working | 19:07 |
| SergeyLukjanov | jogo, re instances - the usecase is to be able to request instance that you'll need in 3 days for 2 weeks, to receive corresponding notifications when vm will be ready, when it'll be time to remove it (to make you able to extend lease) and to have pre-removal snapshot of vm; all of this operations are managed by climate and idea is to support such reservation for different resources including complex ones like heat stacks | 19:07 |
| bauzas | jogo: DinaBelova: I have to step off | 19:08 |
| DinaBelova | bauzas, don't leave me :D | 19:08 |
| bauzas | jogo: DinaBelova: dinner time, ttyl | 19:08 |
| DinaBelova | ok, have a nice time | 19:08 |
| bauzas | well, I placed an order :) | 19:08 |
| bauzas | should have time for discussing in 1h or so | 19:08 |
| DinaBelova | jogo, as I have 23 PM now, I'm dreaming about taking a shower :) Won't you mind to continue discussion in 30 mins? :) | 19:11 |
| jogo | DinaBelova: to be continued then | 19:12 |
| DinaBelova | щл | 19:12 |
| DinaBelova | ok* | 19:12 |
| jogo | SergeyLukjanov: so without spot instances, climate can be implimented with: | 19:12 |
| jogo | some sort of cron as a service (or task engine?), heat, nova (shelving etc). | 19:13 |
| SergeyLukjanov | jogo, heh, are you saying that nova could be implemented by a wrapper for kvm or any other hypervisor? | 19:14 |
| jogo | so I would like to see a clear story of what a reservation means in cinder, swift etc for the incubation discussion | 19:14 |
| jogo | SergeyLukjanov: that is what it is | 19:15 |
| jogo | (in one sense) | 19:15 |
| SergeyLukjanov | jogo, :) | 19:15 |
| SergeyLukjanov | jogo, good point about cinder/swift/etc resources reservation explanation | 19:16 |
| SergeyLukjanov | jogo, re cron as a service - the profit of having separated service to have an api with the way to take info about reservations, ability to prolong them and etc. | 19:17 |
| jogo | SergeyLukjanov: also a clear explination abouot why I am wrong and this can't be done with just heat+cron(task engine?)+etc | 19:17 |
| jogo | SergeyLukjanov: why does that need its own API? | 19:18 |
| jogo | ah hhttps://wiki.openstack.org/wiki/Mistral | 19:18 |
| jogo | https://wiki.openstack.org/wiki/Mistral | 19:18 |
| jogo | Mistral+Heat | 19:19 |
| SergeyLukjanov | jogo, IIRC folks are planning to use Mistral for cron tasks someday | 19:19 |
| jogo | yeah the wiki agrees with you | 19:20 |
| SergeyLukjanov | jogo, you need to store info about reservations somewhere, you should be able to prolong reservations and etc. | 19:20 |
| SergeyLukjanov | I'm not Climate dev, so, I could be wrong somewhere.... | 19:20 |
| jogo | SergeyLukjanov: lets take the use case of: I want to boot a VM for 4 hours every morning | 19:20 |
| jogo | and I cannot risk having it not boot | 19:20 |
| jogo | so I need something to boot my VM, config, shelve it. unshelve in the AM and 4 hours later reshelve | 19:21 |
| jogo | if I want to change that I can just update the mistral workbook | 19:22 |
| jogo | DinaBelova: when you get back ^ | 19:22 |
| DinaBelova | jogo, I'm almost here. It looks like mistral won't help much with physical reservations and energy efficiency | 19:54 |
| bauzas | jogo: DinaBelova: I'm back | 19:58 |
| bauzas | jogo: as DinaBelova said, we're also implementing compute nodes reservations within Climate | 19:59 |
| DinaBelova | at least, now :) we're also planning storage nodes as one more physical reservation :) | 19:59 |
| bauzas | jogo: of course, everything can be done on a deferred way using a cron | 19:59 |
| bauzas | jogo: but can't you think this is not an elegant solution ? | 20:00 |
| bauzas | jogo: I can't hardly see how we could ensure tenancy isolation with only crons | 20:00 |
| jogo | DinaBelova: re physical reservations and energy efficy, agreed but that side of the logic sounds like it belongs in nova or ironic | 20:01 |
| jogo | bauzas: I think using mistarl is an elgant solution | 20:01 |
| jogo | less is more | 20:01 |
| jogo | tenant isolation? that sounds like nova | 20:02 |
| bauzas | tenant isolation for Cinder,mmmm ? | 20:02 |
| bauzas | :) | 20:02 |
| jogo | bauzas: good question | 20:02 |
| jogo | bauzas: so I think there are some interesting ideas be kicked around in Climate, but I am not sure all of them should live in a new service (versus being supported in existing ones) | 20:03 |
| bauzas | jogo: I provided some workflow for managing tenancy isolation and capacity planning thanks to Climate | 20:03 |
| bauzas | with volumes | 20:03 |
| jogo | more use cases would make some of this clearer | 20:03 |
| jogo | bauzas: but at what cost? and what do the cinder people think of that? | 20:03 |
| jogo | so the two use cases you propose are very differnt | 20:04 |
| bauzas | that's why we propose a modular solution | 20:04 |
| jogo | one is a true 'virtual private cloud' full tenant isolation by hardware across all services -- that sounds like an effort of its own | 20:05 |
| bauzas | well, remember the talks we had during Nova sessions | 20:05 |
| jogo | not a project but an effort | 20:05 |
| jogo | bauzas: I don't remember sorry | 20:05 |
| bauzas | it was considered as too big for Nova having a scheduling service | 20:05 |
| jogo | bauzas: so Mistral | 20:06 |
| bauzas | Mistral is about transactional logic | 20:06 |
| bauzas | not a matter of postponing logic | 20:07 |
| jogo | bauzas: in 3 days unshelve this instance? | 20:07 |
| jogo | it says it supports task scheduling as a use case | 20:07 |
| jogo | https://wiki.openstack.org/wiki/Mistral#Tasks_Scheduling_-_Cloud_Cron | 20:07 |
| bauzas | and don't you think Mistral people are thinking about some integration with Climate for achieving this ? | 20:08 |
| jogo | bauzas: that sounds like cirular logic to me | 20:08 |
| bauzas | that sounds different business logics to me | 20:08 |
| jogo | oh? | 20:08 |
| DinaBelova | guys, sorry, I'm almost sleeping :( | 20:08 |
| jogo | bauzas DinaBelova lets move this back to the ML | 20:09 |
| jogo | so others can join | 20:09 |
| jogo | this chat has been very helpful for me, thank you! | 20:09 |
| DinaBelova | I'm glad it was | 20:09 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!