Thursday, 2016-05-26

*** openstack has joined #openstack-watcher00:02
*** harlowja has joined #openstack-watcher00:19
*** thorst_ has joined #openstack-watcher00:33
*** sballe_ has quit IRC00:48
*** openstack has joined #openstack-watcher00:53
*** hvprash has joined #openstack-watcher01:09
*** jwcroppe has quit IRC01:40
*** jwcroppe has joined #openstack-watcher01:40
*** jwcroppe has quit IRC01:45
*** openstackgerrit has quit IRC01:49
*** openstackgerrit has joined #openstack-watcher01:56
*** openstackgerrit has quit IRC01:56
*** openstackgerrit has joined #openstack-watcher01:57
openstackgerritJinquan Ni proposed openstack/watcher: Destination selectors plugin rst
openstackgerritjunjie.huang proposed openstack/watcher: Workload balance migration strategy implementation
*** hvprash has quit IRC02:33
*** openstack has joined #openstack-watcher02:38
*** thorst_ has quit IRC02:51
*** thorst_ has joined #openstack-watcher02:52
*** thorst_ has quit IRC03:00
openstackgerritEdwin Zhai proposed openstack/watcher: Enable strategy parameters
*** thorst_ has joined #openstack-watcher03:58
*** thorst_ has quit IRC04:05
*** hvprash has joined #openstack-watcher04:34
*** hvprash has quit IRC04:39
*** thorst_ has joined #openstack-watcher05:03
*** thorst_ has quit IRC05:09
*** ecelik has joined #openstack-watcher05:44
*** jwcroppe has joined #openstack-watcher05:47
*** jwcroppe has quit IRC05:52
*** hvprash has joined #openstack-watcher06:02
*** thorst_ has joined #openstack-watcher06:07
openstackgerritEdwin Zhai proposed openstack/python-watcherclient: Enable strategy parameter
*** thorst_ has quit IRC06:14
*** hvprash has quit IRC06:15
*** vtech_ has quit IRC06:43
*** openstack has joined #openstack-watcher06:53
*** vtech has joined #openstack-watcher07:02
*** thorst_ has joined #openstack-watcher07:12
openstackgerritjunjie.huang proposed openstack/watcher: Workload balance migration strategy implementation
*** thorst_ has quit IRC07:20
*** jed56 has joined #openstack-watcher07:20
*** vincentfrancoise has joined #openstack-watcher07:23
openstackgerritEdwin Zhai proposed openstack/watcher: Enable strategy parameters
*** jwcroppe has joined #openstack-watcher07:50
*** jwcroppe has quit IRC07:55
*** vtech has quit IRC08:07
*** vtech_ has joined #openstack-watcher08:07
*** thorst_ has joined #openstack-watcher08:17
*** thorst_ has quit IRC08:25
openstackgerritAlexander Chadin proposed openstack/watcher: Add continuously optimization
*** alexchadin has joined #openstack-watcher08:39
openstackgerritVladimir Ostroverkhov proposed openstack/python-watcherclient: Add support continuously-optimization
jinquanalexchadin hello?08:53
alexchadinjinquan: hi!08:53
jinquanI have a question about vm_workload_consolidatin08:54
jinquani'm work on this BP, now I need refactor the select_destination in all startegies08:55
jinquanbut i'm not sure   the vm_fits  need refactor  in vm_workload_consolidation08:56
jinquando you have some suggest?08:56
alexchadinwait a sec please08:57
jinquanOK thank you very much!:)08:57
alexchadinName of my strategy is workload_stabilization08:58
alexchadinDo you mean this or vm_workload_consolidation?08:58
vincentfrancoisejinquan, alexchadin: both will need refactoring at some point08:59
jinquanI am mean vm_workload_consolidation09:00
jinquanand workload_stabilization has merged?09:00
vincentfrancoisejinquan: both names are similar so I got confused when you asked me earlier09:01
alexchadinNo, workload_stabilization hasn't been merged yet09:01
vincentfrancoisefor vm_workload_consolidation, you can ask vtech_09:01
jinquannothing , i find the author in code, ok i will ask vtech09:02
vincentfrancoisebut alexchadin, if you can have a look at what jinquan is doing, that would ease the refactoring ;)09:02
jinquanvincentfrancoise,alexchadin thank you !!09:03
alexchadinI will once I have a free time, ok, jinquan?09:03
jinquanvtech_: hello?  are you online?09:03
jinquanalexchadin: of course!:)09:04
vtech_hello guys, yep I am here.09:04
alexchadinvincentfrancoise: continuously-optimization patches have been commited for watcher and python-watcherclient09:04
vtech_let me catch up what's going on here ;)09:05
jinquancan you read the info above and give us some help ?09:05
vincentfrancoisealexchadin: I'm doing reviews this morning, so I'll try to review it as well09:06
alexchadinvincentfrancoise: great :)09:06
vtech_jinquan, ok, I will check it out, but I will need few minutes.09:08
jinquanvtech_: OK09:09
jinquan vincentfrancoise: can i propose new patch set that already refactor outlet_temp_consolidation?09:10
vincentfrancoisejinquan: go ahead but I'll review alexchadin's code first so I certainly won't review it today anyway09:15
vtech_jinquan, it might be a little bit complicated here "vm_fits" ( checks whether a is a hypervisor able to accomodate VM considering cpu, ram and disk metrics including capacity coefficients (for underbooking / overbooking)09:16
jinquanvincentfrancoise: ok, the new patch need's more info form  vtech_. then we will konw the patch will go09:17
vtech_jinquan, the algorithm iterates through the destination hypervisors sorted ASC in the offloading and DSC in the consolidation phase based on PREDICTED hypervisor CPU load09:18
jinquanvtech_:yeah , it check one host one  time  and it's based on vm cpu/mem/disk util from ceilometer .09:19
jinquanvtech: am i right?09:19
vtech_the strategy internally has a model which predicts the cpu load of hypervisor load as the migrations are added to the solution (before they are actually applied in applier)09:19
vtech_the whole strategy creates a deep copy of the model in the very beginning and then operates on a "prediction model"09:21
vtech_e.g. considering two host environment (host A, host B) with VM1 (on A) and VM2 (on B)09:22
*** thorst_ has joined #openstack-watcher09:22
jinquanvetch_: and you does this beacuse you need avoid the situation like "pingpong"?09:24
jinquanvtech_:So it seems like refactor to use select_destination are diffcult?09:24
vtech_once I add a migration to the solution (lets say migrate VM1 from A->B), the resource utilization is predicted so host A util = host A util  - VM A util and host B util = host B util + vm A util09:25
vtech_yes IMO it might be very difficult, and I don't think it's a good idea to only have one unified way how to select destination hypervisor09:26
jinquanvtech_:oh, we can implement a new way in new destinations selector09:28
vtech_so in the strategy we query ceilometer only once at the beginning, because as you are adding migrations you can expect the load on the host to change accordingly but this is not reflected in ceilometer metrics until you actually move the VMs arround09:28
*** thorst_ has quit IRC09:30
vtech_ie. let's assume you have a hypervisor with 0 load. If you only query ceilometer during the computation (solution generation) this hypervisor will still appear with 0 load. But this is extremely as it doesn't reflect migration which will destinate (and thus will affect) hypervisor's load.09:33
jinquan vtech_  vincentfrancoise: Ok, i see, IMO, selector a destination has two aspects: watcher and nova .  to watcher  this is decide by difference stategy. to nova  we need check cpu/mem/disk  and so on. I think we should mix the two aspects09:34
jed56vtech_: I agree, that every strategy can  have their own concern.09:34
jed56However, the strategies have to respect the policies Group (Affinity, no-affiniy, etc)09:34
jed56IMHO, the stragey can propose a list of possible "destinations" and the select_destination is in charge of check the constraints.09:35
vtech_jed56, true, this is not implemented in our strategy to date09:35
jinquans/should/should not09:35
vtech_jed56, this sounds sensible to me.09:36
jed56The main aim of select_destination is verify only the constraints09:36
jed56we are working with nova09:36
jed56to improve the selection_destination09:36
vtech_jed56, I am aware of the affinity constraints, it's a very good point09:37
jed56We wants that  nova accept  multiple hosts when calling live migration09:37
jed56this is the reason why we want to propose a "common way" to do it in watcher09:37
jed56we will to adapt every strategy to call this "super checker"09:38
jed56we will need to adapt every strategy to call this "super checker"09:39
vtech_jed56, can you prioritize them?09:39
vtech_that would solve the problem I think09:39
vtech_so you only pass nova hypervisors with desired priority for where you want your VM to land09:40
jinquan jed56:  Ok , i see .  "super checker" is that i said "selector for nova aspect "? am i right?09:40
jed56jinquan: yes09:41
vtech_and nova scheduler will go through them by the priority and lands returns you the destination of the first match.09:41
jed56vtech_:  yes this is the idea09:42
jed56but i'm not sure that nova will accept a list with priority :)09:42
jed56the other solution is to retrieve the constraints from nova through the RequestSpec or from congress09:43
jed56but I'm not sure that nova will appreciate this solution09:43
vtech_jed56, yeah, but I am sure nova guys will be happier when the nova scheduler can make "the final decision"09:43
jed56yes, this why they should adapt their API09:44
vtech_I like the idea of sending multiple destination options, once this support prioritization, you can still make some impact on the final placement in strategy and nova guys will stay happy as the nova scheduler "approves" your choice09:46
jed56vtech_: me too :)09:47
vtech_but now i can see an uncertainity computing the solution in my strategy.09:48
jed56yes, I agree09:50
vtech_as nova decides the location when migration actually start (in applier), there is no way how to predict where the VM land during the computation.09:50
jed56jinquan: I didn't take a look to your code, are you align with this discussions ?09:50
vtech_and to be frank I am not 100% sure how to modify our strategy to this.09:51
jed56vtech_: we can force the destination in the applier or write a plugin in nova09:51
jed56vtech_: I have to go we continue the discussion later09:51
jinquani'm  reading your discussion09:51
jed56this is a very hot topic09:51
jed56We have two priority in watcher scalability and constraints09:52
vtech_ok, if we can force this, there is no problem with the strategy, but then (again) we are taking some responsibillity from nova09:52
vtech_I will think about this...09:53
*** jwcroppe has joined #openstack-watcher09:53
jed56vtech_: no, if we ask nova if this is a possible solution through the select_destination09:53
jinquanyou mean target destinations  with live-migration ?09:53
jed56I'm sorry i have to go09:53
vtech_jinquan, yes09:54
jinquanvtech_: do we have a commit bp in nova?09:55
*** jwcroppe has quit IRC09:58
vtech_jinquan, so the conclusion is: the vm consolidation strategy computes the placement on the go ie. it requires certainty in terms of desired destination will be the actual destination and there is not much room for uncertainity afaik. I will have to think about this a little bit more.09:59
vtech_jinquann, I will also check the current status of nova to see whether to blueprint allowing to specify multiple destination is a solution for this particular case.10:01
vtech_I will have to go now10:01
jinquanOK. thank you very much10:01
vtech_np, thanks for bringing it up10:02
vtech_jinquan, bye10:02
openstackgerritJinquan Ni proposed openstack/watcher: Select destinations filter implementation
openstackgerritJinquan Ni proposed openstack/watcher: Select destinations filter implementation
*** thorst_ has joined #openstack-watcher10:28
*** thorst_ has quit IRC10:35
*** alexchadin has quit IRC10:41
openstackgerritVincent Françoise proposed openstack/python-watcherclient: Replaced UUID of goal and strategy with name
openstackgerritVincent Françoise proposed openstack/python-watcherclient: Update Watcher CLI documentation
openstackgerritVincent Françoise proposed openstack/python-watcherclient: Updated CLI to display efficacy related fields
*** thorst_ has joined #openstack-watcher11:49
*** jwcroppe has joined #openstack-watcher11:56
*** jwcroppe has quit IRC12:01
*** hvprash has joined #openstack-watcher12:51
*** jwcroppe has joined #openstack-watcher12:58
*** hvprash_ has joined #openstack-watcher12:59
*** hvprash has quit IRC13:03
*** jwcroppe has quit IRC13:05
openstackgerritMerged openstack/watcher-dashboard: Added Goals and Strategies to Dashboard
*** lrensing has joined #openstack-watcher13:39
*** vincentfrancoise has quit IRC13:43
*** vincentfrancoise has joined #openstack-watcher13:45
*** vincentfrancois1 has joined #openstack-watcher13:45
*** vincentfrancois1 has quit IRC13:46
*** vincentfrancoise has quit IRC13:46
*** vincentfrancoise has joined #openstack-watcher13:52
*** ecelik has quit IRC13:59
*** jwcroppe has joined #openstack-watcher14:57
*** hvprash_ has quit IRC15:13
*** hvprash has joined #openstack-watcher15:13
*** hvprash has quit IRC15:48
*** hvprash has joined #openstack-watcher15:48
*** vtech_ has quit IRC15:56
*** vincentfrancoise has quit IRC16:21
*** vtech has joined #openstack-watcher16:26
*** wootehfoot has joined #openstack-watcher16:47
*** hvprash has quit IRC17:29
*** hvprash has joined #openstack-watcher17:31
*** ss4 has joined #openstack-watcher17:33
*** ss4 has quit IRC17:35
*** ss4 has joined #openstack-watcher17:35
*** wootehfoot has quit IRC17:36
*** hvprash_ has joined #openstack-watcher17:42
*** hvprash has quit IRC17:44
*** hvprash has joined #openstack-watcher17:46
*** hvprash_ has quit IRC17:49
*** ss4 has quit IRC18:31
*** lrensing has quit IRC19:14
*** esberglu has joined #openstack-watcher19:59
*** thorst_ has quit IRC21:10
*** thorst_ has joined #openstack-watcher21:10
*** thorst__ has joined #openstack-watcher21:12
*** thorst_ has quit IRC21:15
*** thorst__ has quit IRC21:16
*** hvprash_ has joined #openstack-watcher22:13
*** hvprash_ has quit IRC22:13
*** hvprash has quit IRC22:16
*** jwcroppe_ has joined #openstack-watcher23:21
*** jwcroppe has quit IRC23:23
*** hvprash has joined #openstack-watcher23:47
*** hvprash has quit IRC23:51

Generated by 2.14.0 by Marius Gedminas - find it at!