15:02:00 <gchaplik_> #startmeeting 15:02:00 <ovirtbot> Meeting started Mon Dec 2 15:02:00 2013 UTC. The chair is gchaplik_. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:00 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:02:08 <gchaplik_> #topic oVirt 3.4 SLA & Scheduling features 15:02:27 <gchaplik_> #info brief description of oVirt 3.4 SLA & Scheduling features 15:03:23 <gchaplik_> #info agenda 15:03:32 <gchaplik_> each team member will talk about his feature: 15:03:59 <gchaplik_> #info time based policy (SLA during the day, power saving at night) (Kobi) 15:04:08 <gchaplik_> #info application level HA (monitor the service inside the VM) (Jiri) 15:04:15 <gchaplik_> #info power saving policy moving hosts to sleep (Martin) 15:04:26 <gchaplik_> #info positive/negative affinity between group of VMs (Gilad) 15:04:33 <gchaplik_> #info others (Doron) 15:04:53 <gchaplik_> #topic time based policy (SLA during the day, power saving at night) 15:05:10 <gchaplik_> let's start, I'd like to invite Kobi to talk about time based policy (SLA during the day, power saving at night) 15:05:57 <kobi> Hi All 15:06:24 <kobi> feature: 15:06:33 <kobi> Time Based Policy BZ=1036729 15:06:45 <kobi> description: 15:06:56 <kobi> The Time Based Policy feature allows the user to select different cluster policy for different configurable periods of time. 15:07:25 <kobi> in a few words: 15:07:39 <kobi> In the current flow available the user can select the policy he wishes to apply to the cluster, for example Power Saving. 15:07:39 <kobi> The new Time Based Policy will expand the policy capabilities and will allow the user to select multiple policies that each one of them will be active at different times. 15:07:39 <kobi> A good use for this feature will be a Time Based Policy that is configured to use Evenly Distributed on work days and Power Saving on weekends. 15:08:40 <kobi> for the user interface implementation we have thought about two solutions. 15:08:40 <kobi> 1st: 15:08:40 <kobi> in the Cluster new/edit popup window, at the Cluster Policy section, 15:08:40 <kobi> there will be a possibility to select Time Based Policy. 15:08:40 <kobi> when selected, the Policy's properties will show. 15:08:42 <kobi> the properties will be as followed: 15:08:44 <kobi> DefaultPolicy - the default policy to use when no other policy was selected. 15:08:46 <kobi> FirstPolicyName - a policy from the existing pool of policies (configured under Configure->Cluster policies). 15:08:49 <kobi> FirstPolicyStartTime - the time that the policy kicks in to action, this field we accept cron expressions. 15:08:51 <kobi> FirstPolicyDuration - the duration that the policy will be active. 15:08:53 <kobi> SecondPolicyName - same as FirstPolicyName. 15:08:59 <kobi> SecondPolicyStartTime - same as FirstPolicyStartTime. 15:09:01 <kobi> SecondPolicyDuration - same as FirstPolicyDuration. 15:09:03 <kobi> 2nd (preferred): 15:09:05 <kobi> in the Cluster new/edit popup window, at the Cluster Policy section, 15:09:07 <kobi> there will be a possibility to select Time Based Policy. 15:09:09 <kobi> when selected, the Policy's properties will show. 15:09:13 <kobi> the properties will contain a scheduler bar(similar to a mail appointment scheduler bar). 15:09:15 <kobi> the user will select sections on the bar and assign them to policies from the existing pool of policies (configured under Configure->Cluster policies). 15:10:17 <kobi> basicly thats it. any Qs? 15:10:44 <alitke> kobi, are there more than 2 policies allowed? 15:11:22 <kobi> in the second solution there can be more the 2 15:11:37 <msivak> kobi: but not at the same time right? 15:11:47 <alitke> ok... In my opinion, a limit of 2 is unacceptable. 15:11:50 <itamar> +1 to 2nd option. 15:11:57 <itamar> much more intuitive. 15:12:02 <ecohen> +1 to 2nd option too. 15:12:16 <kobi> in the first solution we are limited to a predefined number 15:12:43 <alitke> hopefully there is an existing widget that allows selection of time intervals. 15:13:02 <ecohen> kobi, not necessarily - there can be solutions to that (e.g. something similar to custom properties, with "+" and "-" buttons; but the 2nd way is simply more intuitive, as Itamar mentioned. 15:13:05 <doron> msivak: not at the same time 15:13:27 <sherold> While unattractive, even start/end time fields with a policy dropdown with error validation to prevent overlap 15:14:17 <kobi> ecohen: you are right, 10x for the idea 15:14:24 <itamar> question is representation / capabilities. then gui i think. 15:14:28 <gchaplik_> okay guys we'll more time for questions in the end 15:14:34 <gchaplik_> I'd like to move on... 15:14:55 <gchaplik_> #topic application level HA (monitor the service inside the VM) 15:15:11 <itamar> assuming at any time only one policy is possible, doing it time based seems easier (for 24*7). if we need something more sophisticated (first of the month, etc. a bit more tricky. 15:15:12 <gchaplik_> I'd like to invite Jiri to talk about application level HA (monitor the service inside the VM) 15:15:25 <jmoskovc> Hi All 15:15:58 <jmoskovc> the application HA feature should allow users to define a list of applications to be watched inside the VM 15:17:20 <jmoskovc> and if the application stops working it would do some predefined action, send a notification to the engine, restart the app (tricky), or restart the whole VM 15:17:44 <jmoskovc> or just show a warning message 15:18:01 <jmoskovc> my tentative design: 15:18:30 <jmoskovc> There should be a list of all service somewhere on the Virtual Machine tab, either a new tab "Services" can be added or we can use the "Applications" tab for it 15:19:12 <jmoskovc> Every service in the list would have a checkbox saying "Watch this service" 15:19:23 <jmoskovc> if it's marked then the engine would send the name of the service to guest agent and the agent would send a warning if the service changes it's state to "not running" 15:19:56 <jmoskovc> and there should be also a combo to select the action to do when the service stops working 15:21:18 <jmoskovc> the guest agent should provide an API to set the list of the watched services and get their states (maybe some tweaks will be needed) 15:22:03 <jmoskovc> and we need to store the list of watched services and actions to the database 15:22:58 <jmoskovc> that's basically it 15:23:08 <itamar> jmoskovc: how does engine knows which services can be monitored by guest agent? how do you update/validate the guest agent configuration of services to be monitored? 15:23:32 <jmoskovc> itamar: guest agent would send a list of services which can be monitored 15:23:44 <doron> right 15:23:55 <itamar> no deduced from its version? 15:24:27 <jmoskovc> itamar: first version of this feature would just support the system services 15:24:43 <itamar> jmoskovc: what do you mean by system services? 15:24:46 <jmoskovc> so guest agent would just return the list of all the services reported by the OS 15:25:01 <doron> ie- standard services 15:25:04 <msivak> itamar: anything that systemd/windows reports as a service 15:25:05 <itamar> and their status running/stopped? 15:25:10 <jmoskovc> yes 15:25:24 <sherold> Could also be nice to at least have a hook for a user to provide a quick custom script. For Example: check HTTP status (returns 200) and return a proper status code saying "Still good", or "httpd is running, but not properly responding", perhaps for a phase 2. 15:25:50 <itamar> how do we make sure the design is generic to cover future use cases and not having to code for each? i.e., what's the next reuqest? 15:26:08 <itamar> we know for ovirt-engine the service is not the interesting part, hence we have a check health servlet 15:26:10 <jmoskovc> yes, the proper detection of "not working" is tricky 15:26:18 <doron> itamar: as long as we use standard system services we should be ok 15:26:21 <jmoskovc> is ti stuck, is it busy? 15:26:56 <jmoskovc> so for now, it's only running or not runnig as reported by the system service management (systemd, windows, etc..) 15:27:38 <srevivo> question, if i have several VM's running the same application... how can i aggregate ? 15:27:50 <doron> btw, for specific cases we may be able to use a watchdog device 15:28:00 <doron> srevivo: it's per vm. 15:28:21 <itamar> no configuration needed from engine to guest agent at later phases? 15:28:29 <itamar> which port to monitor for a service, etc? 15:28:33 <srevivo> i see, but what is the use of having it per VM while customers want to monitor application ... 15:28:48 <itamar> thoughts on integrating with a monitoring system or its agents? 15:29:00 <srevivo> exactly ... 15:29:10 <msivak> srevivo: how do you identify the app across cluster? 15:29:15 <itamar> or thoughts if this should be a guest service or an external service monitoring health as visible externally to the vm? 15:29:46 <srevivo> what is the use case we are trying to cover ? 15:30:06 <srevivo> sorry for joining a bit late (in case someone already explained) 15:30:10 <doron> srevivo: the originl request was 15:30:32 <doron> for basic service monitoring 15:30:40 <doron> as described here. 15:30:44 <doron> anything more advanced 15:30:58 <doron> should be considered with other platform / services 15:31:13 <doron> such as nagios / heat + ceilometer, etc 15:31:36 <doron> and to be honest, 3.4 does not have the time for such a scope. 15:31:47 <srevivo> Exactly, i don't see any data center running without such tools 15:31:51 <doron> yet we should be able to come up with something useful. 15:32:10 <srevivo> this is why i am asking about the value of developing it 15:32:35 <msivak> doron: I agree, although we could teach guest agent to collect nagios/rrdtool/.. data and display them in the admin console 15:32:47 <doron> srevivo: so I do think it has a value for basic common cases 15:33:15 <doron> and for distributed apps we should think of an advanced feature. or- 15:33:30 <doron> as it is becoming today highly-available apps, 15:33:42 <doron> which means the apps should be highly available aware 15:34:24 <doron> anyway I suggest we discuss it in the ML to allow other features to be presented. 15:34:27 <srevivo> most of the apps today are such and usually the interesting part is the app SLA and not a specific VM status 15:34:53 <srevivo> agree :-) 15:35:06 <doron> srevivo: to a reasonable extent. let's discuss it in length in the ML. 15:35:22 <gchaplik_> gr8, lets continue, I'd like to invite Martin to talk about 'power saving policy moving hosts to sleep' 15:35:27 <gchaplik_> #topic power saving policy moving hosts to sleep 15:35:39 <gchaplik_> Martin go ahead 15:35:46 <msivak> hi everybody 15:35:48 <itamar> gchaplik_: sleep or shutdown? 15:35:48 <msivak> Support for moving hosts to sleep when using Power Saving policy 15:36:02 <doron> itamar: ^^^^^ 15:36:08 <msivak> itamar: well probably shutdown for now 15:36:18 <msivak> sleep is tricky.. 15:36:36 <msivak> http://www.ovirt.org/Features/HostPowerManagementPolicy 15:36:36 <msivak> https://bugzilla.redhat.com/show_bug.cgi?id=1035238 15:36:38 <itamar> so powermanagement needed to be configured to wake them up? wake-on-lan? 15:36:39 <srevivo> although boot will be quicker 15:36:48 <msivak> Goals: 15:36:48 <msivak> - shutdown a host when Powersaving is selected and engine clears the host (migrates all VMs elsewhere) 15:36:48 <msivak> - wake up a host when the available resources get below configured level 15:37:00 <msivak> Design: 15:37:00 <msivak> - shutdown methods: standard engine's fencing methods - IPMI, SSH, Drac 15:37:00 <msivak> - wake methods: standard methods - IPMI, SSH, ... - with fallback to WOL when needed and supported 15:37:00 <msivak> - use Start/StopVdsCommand internally 15:37:00 <msivak> - bogomips used as the CPU power unit (/proc/cpuinfo) 15:37:15 <msivak> Shutdown rules: 15:37:16 <msivak> - host is empty 15:37:16 <msivak> - there is enough available CPU-power in the cluster without this host 15:37:16 <msivak> - make sure spm is not killed 15:37:16 <msivak> - consider keeping an extra host 15:37:27 <msivak> Wake Up rule: 15:37:27 <msivak> - not enough free resources in the cluster 15:37:27 <msivak> - probably a separate thread or VdsUpdateRuntimeInfo based periodic check 15:37:33 <msivak> Support needed from VDSM: 15:37:33 <msivak> - CPU power information - /proc/cpuinfo's bogomips per CPU 15:37:33 <msivak> - [WOL] each host has to report MAC and WOL capability for each NIC 15:37:33 <msivak> - [WOL] locality information to know who can send the proper WOL packet (each host will report it's ARP database of visible MAC addresses for each NIC) 15:37:33 <msivak> UI: 15:37:35 <msivak> - Cluster policy needs to allow the user to set the minimum amount of free resources (hosts / CPU / RAM) and whether host shutdown is allowed 15:37:55 <msivak> so to answer the questions 15:38:08 <msivak> I would start with shutdown first 15:38:23 <msivak> and use our existing fencing mechanisms to control the hosts 15:39:02 <msivak> we can implement WOL as an additional method, but that requires some additional support from vdsm 15:39:51 <itamar> why separate thread and not part of normal scheduling (every minute iirc)? 15:40:13 <msivak> that is an option as well 15:40:24 <msivak> I forgot about the balancing thread 15:40:33 <itamar> why WOL for each nic and not just mgmt nic? 15:40:42 <doron> msivak: right, the idea is to use it in load balancing. 15:40:59 <msivak> itamar: to have better chance of getting a path 15:41:21 <itamar> why list of arp, etc. - any host in same cluster should be able to WOL other hosts - they are on same layer 2 (more than likely)? 15:43:10 <doron> itamar: if this is an assumption we can take, it will make our life easier. 15:43:14 <msivak> itamar: I do not really have an answer for this, my setup has a host that is outside L2 :) 15:43:42 <doron> unless we want to support SDNs ;) 15:44:21 <msivak> doron: well think about our env in Brno, we have multiple server rooms 15:44:46 <msivak> doron: and some of the machines are inside of routed vlan 15:44:56 <itamar> hosts in same cluster are expected to be in same layer 2. otherwise live migration of VMs won't work as well. 15:45:09 <itamar> we can most likely assume that for the mgmt interface as well. 15:45:26 <doron> +1 for phase 1. 15:45:39 <ecohen> msivak: implied earlier, but wanted to make sure: Only Hosts that have fence agents defined would be able to be candidates for sleep, correct (at least while we intend to use existing fencing mechanisms)? 15:45:43 <itamar> also, WOL is a nice addition. its basically a new fence agent - [ssh|vdsm]-shutdown / WOL 15:46:07 <msivak> ecohen: yes, there is no other way of shutting them down atm 15:46:16 <itamar> so i assume worth to first just start with the existing fence devices (require pm configuration), and only later enhance for soft fencing/wake up. 15:46:31 <msivak> agreed 15:46:46 <gchaplik_> #agreed assume all hosts in same L2 15:47:21 <gchaplik_> #agreed used existing fence devices 15:47:30 <gchaplik_> moving on 15:47:40 <gchaplik_> I will talk about positive/negative affinity between group of VMs 15:47:45 <gchaplik_> #topic positive/negative affinity between group of VMs 15:47:51 <gchaplik_> VM Affinity: definition 15:47:59 <gchaplik_> Policy/set of rules that make VMs run together (possitive) or separated (negative). 15:47:59 <gchaplik_> This policy can be mandaotry or optional (best effort). 15:48:31 <gchaplik_> positive VM affinity helps reduce traffic across networks, i.e - If two virtual machines communicate frequently and should share a host, we can create a positive affinity rule to make them run on the same host. 15:48:31 <gchaplik_> Conversely, loaded VMs can have a negative (anti-)affinity rule that will keep the VMs from sharing a host and exhaust its resources. 15:48:49 <gchaplik_> currently we decided that the scope of the feature for 3.4 will be VM-VM affinity. 15:49:01 <gchaplik_> high-lever design: we'll add an affinity object, with the following attributes: 15:49:01 <gchaplik_> - positive/negative affinity 15:49:01 <gchaplik_> - mandatory/optional 15:49:01 <gchaplik_> - set of hosts 15:49:15 <gchaplik_> each VM can be attached to an Affinity object and will act according to its rules when scheduling the VM (running/migrating). 15:49:16 <gchaplik_> by using the filtering and scoring mechanisms introduced in the Scheduler, it is now posible to add an affinity filter and weight function: 15:49:37 <gchaplik_> Affinity Filter for mandatory affinity - using an hard constraint to filter out host that doesn't meet the mandatory affinity rules. 15:49:45 <gchaplik_> Affinity Weight function for optional affinity- target Hosts that match the optional condition will get a lower weight (higher score) than hosts that do not match the condition, which will ultimately position them higher in the priority list. 15:50:07 <gchaplik_> my open questions: 15:50:09 <gchaplik_> - a VM can be attach to several affinity object, and there may be conflicts which cause the vm to end up with no hosts. we need to decide how to handle that. 15:50:10 <gchaplik_> - can HA VMs violate affinity rules? 15:50:10 <gchaplik_> - how load balancing affects affinity, the load balancing isn't aware of it... 15:50:10 <gchaplik_> - UI: should we show the affinity object? we can just attach VM to VM (with params) and hide the object from the user. 15:50:42 <itamar> is this admin level feature or power user as well? are affinity groups managed entities with permissions? 15:51:04 <msivak> gchaplik_: can you have more affinity rules per vm? 15:51:13 <gchaplik_> itamar: lets start with admin 15:51:59 <gchaplik_> itamar, about permissions it depends if we want to hide it 15:52:21 <gchaplik_> msivak: yes 15:52:38 <msivak> gchaplik_: I would hide the objects, but show a list of relationships on a VM subtab 15:53:15 <ecohen> gchaplik_, can you explain a bit the relation to the 'set of Hosts'? if I want to define that VM1 must always run with VM2 - what is the 'set of Hosts' involvement in it? 15:53:20 <doron> msivak: this can end up being noisy 15:53:50 <msivak> doron: do we have any VM groups/tags concept? 15:54:04 <doron> msivak: we have an rfe for it 15:54:35 <msivak> doron: we could group the VMs and base the affinity on group membership 15:54:48 <sherold> ecohen: Some apps may have strict (and ridiculous) licensing requirements (like certain database companies). Ability to pin VMA and VMB to licensed Host1 is a valid use case 15:54:58 <msivak> doron: that would make it less noisy and in alignment with our policy plan "documents" 15:55:20 <doron> msivak: basically the new entity gives you this functionality 15:55:34 <ecohen> sherold, sure - it just doesn't sound related to the VM Affinity feature - this is why we have the "run only on host" feature... 15:55:41 <doron> without creating new hierarchies in the system 15:56:10 <doron> ecohen: I agree basic vm affinity should be kept simple 15:56:21 <doron> ie- hosts are another layer we may add later 15:56:34 <doron> but basic functionality is vm-vm relations. 15:56:38 <ecohen> doron, but the use-case is what sherold mentioned above? 15:57:18 <doron> ecohen: yep. opnce vm a is pinned to host1 15:57:23 <msivak> gchaplik_: so the idea is to create a group with defined affinity and a list of VMs that belong to it? 15:57:27 <doron> other vms will follow that 15:57:29 <sherold> ecoehn: Perfect, scenario/requirement satisfied ;-). 15:57:38 <ecohen> doron, sherold : thanks. 15:58:22 <gchaplik_> msivak: sort of 15:58:45 <gchaplik_> any other question..? 15:58:48 <gchaplik_> s 15:59:37 <gchaplik_> #topic additional RFEs 15:59:42 <gchaplik_> Doron 15:59:53 <doron> ok some additional RFE's we're now designing 15:59:59 <msivak> doron: what if the pinned vm is not running? 16:00:13 <doron> si this is just a brief explanations on them 16:00:21 <doron> msivak: let's keep it for the end. 16:00:24 <msivak> sure 16:00:31 <doron> High Availability flag should be included when exporting/importing from Export Domain 16:00:41 <doron> this is basically a nit we want to cover 16:01:05 <doron> missing flag we need to update in the OVF file. 16:01:33 <doron> nothing dramatic about it. 16:01:41 <doron> so I'll proceed to the next one; 16:01:44 <doron> Even Distribution Policy by number of VMs 16:02:05 <doron> this is an new additional policy we'll add 16:02:28 <doron> which basically does distribution by counting VMs instead of considering CPU load. 16:02:54 <doron> As the standard even distribution does. 16:03:21 <doron> Quite straight forward. Any questions on it? 16:03:54 <mrao> I think the policy name should clarify the distinction from standard even distribution 16:03:57 <doron> I'll take that as a 'no' ;) 16:04:12 <doron> mrao: good ppint 16:04:58 <gchaplik_> #agreed Even Distribution Policy by number of VMs policy name should clarify the distinction from standard even distribution 16:05:10 <doron> I'll proceed to the next one 16:05:14 <doron> Make reservations for HA VMs to make sure there's enough capacity to start them if N hosts fail 16:05:26 <doron> this is not a trivial one. 16:05:57 <doron> I'm looking into implementing it using the new oVirt scheduler, so will provide more details when we have a clear picture of it. 16:06:39 <doron> in general it means we should sustain a loss of several hosts and still retain capacity for HA VMs. 16:06:58 <doron> Questions? 16:07:48 <doron> I'll take that as a 'no' as well. 16:08:06 <doron> Next one is Memory capping using cgroups 16:08:17 <doron> this is basically closing a gap we have 16:08:32 <doron> on forcing a limit on memory consumption of a VM. 16:08:43 <doron> currently we can balloon it wit hsome limitations 16:08:58 <doron> but missing a hard limit which we'll have in 3.4 using cgroups. 16:09:18 <doron> Questions? 16:09:20 <sherold> All I ask is that we're careful and don't artificially cause the host to massively swap when it's not necessary (aka VMware) 16:09:47 <doron> #agreed to be careful when using this limitation. 16:10:06 <doron> Other questions / comments? 16:10:08 <msivak> well this is hard cap, that won't affect swapping 16:10:24 <msivak> ballooning and overcommitment might though :) 16:10:30 <sherold> Exactly 16:10:32 <doron> msivak: it can actually affect swapping 16:10:57 <doron> if guest has no sufficient ram, it will swap 16:11:10 <sherold> Background on what I want to avoid - http://www.vmguru.com/articles/hypervisor/7-memory-behavior-when-vm-limits-are-set-revisited 16:11:16 <msivak> doron: sure, but sherold talked about hosts 16:11:37 <doron> msivak: I suspect it will affect the host. 16:11:55 <doron> very well, let's proceed. 16:12:05 <doron> rhev-h support for hosted engine nodes 16:12:15 <itamar> ovirt-node you mean ;) 16:12:17 <doron> this one may endup as a setup issue for the integration group 16:12:24 <doron> itamar: right ;) 16:12:55 <doron> basically now hosted engine supports fedora / rhel only. 16:13:00 <doron> (centos, etc) 16:13:16 <doron> and we should provide the support from ovirt node. 16:13:29 <doron> Questions? 16:13:48 <itamar> plans for TUI or just packaging? 16:14:03 <itamar> s/packaging/inclusion/ 16:14:14 <itamar> (and persistence of files) 16:14:19 <doron> itamar: depends on capacity. will check with fabiand and others 16:14:48 <doron> I assume it will be included, and deploy will run the relevant bits. 16:15:07 <doron> with the ovirt node requirements suh as persistence. 16:15:25 <doron> other questions? 16:15:53 <doron> Very well, almost there... 16:16:02 <doron> hosted engine on san 16:16:15 <doron> Currently hosted engine supports NFS only and we need to extend it 16:16:37 <doron> sice we are using vdsm code, I expect the architecture to be fine, with 16:16:42 <doron> nits we'll need to resolve. 16:17:12 <doron> (hopefully ;) 16:17:24 <doron> Questions? 16:17:41 <doron> One more hosted engine- 16:17:43 <doron> Unify maintenance path of hosted engine with host maintenance 16:18:07 <doron> basically hosted engine has a special maintenance mode which disarms the HA services. 16:18:29 <doron> This feature should unify the standard 'maintenance host' flow with 16:18:42 <doron> hosted engine maintenance. 16:19:10 <doron> The idea is to extend VDSM API, so the engine will ask vdsm to move the HA services to maintenance 16:19:34 <doron> and it should all be a part from the existing host maintenance flow. 16:19:48 <doron> That's it for this feature. Any questions? 16:20:33 <doron> very well. This finalizes the SLA & Scheduling features. Back to Gilad. 16:20:42 <gchaplik_> Thanks doron, 16:20:55 <gchaplik_> Last chance for questions? 16:20:59 <itamar> on vm affinity - we know vm groups are a requirement for other things (like permissions), maybe separate them from affinity (i..e, add support for (vm) groups, then allow affinity to them) 16:21:42 <gchaplik_> itamar: vm taging? 16:22:13 <msivak> yeah, that is what I had in mind as well 16:22:15 <sherold> Tagging seems simple as there is a mechanism that exists for it today 16:22:36 <doron> The thing is that negative affinity is an 'anti-group' 16:22:46 <itamar> sherold: only if we make tags first class citizens, and add permission around tags. 16:22:52 <doron> we may get complicated for something we did not plan for 16:22:59 <doron> also 16:23:00 <itamar> also, a bit confusing is that a tag can contain both vms and hosts (and templates, pools, users) 16:23:03 <itamar> ? 16:23:06 <sherold> Hmmm 16:23:17 <itamar> so we need to decide if tags is our way to go in the future before basing more stuff on it. 16:23:18 <doron> we may want to mix afinity of vm and nework for example 16:23:27 <doron> or vm and host 16:23:33 <sherold> Longer term, yes... Affinity will be more than VM:VM 16:23:59 <sherold> Separate storage devices/paths, etc 16:24:01 <itamar> there are no permissions around tags, they may be used for something else. 16:24:05 <itamar> also, they are hiearchical. 16:24:19 <itamar> I'm really not sure they are the best fit for this. 16:24:31 <msivak> doron: negative affinity on network is possible, positive.. is there a use case for it? 16:24:34 <itamar> too many inconsistencies/complexities 16:24:48 <itamar> networks not yet supported by tags. and networks are on all hosts in the cluster... 16:24:55 <doron> msivak: let's start with negative vm:vm 16:25:18 <msivak> doron: vm:vm is technically easy, the question is how to present it to the user 16:25:41 <doron> msivak: if we use affinity 16:25:46 <doron> as a hidden object 16:25:49 <doron> just like MLA 16:26:06 <doron> we can work with it while presenting the relevant relations where needed 16:26:47 <doron> msivak: so we can represent relations between VM 16:26:50 <itamar> doron: i think the more correct approach is to based it on vm groups. an entity we can manage permissions for 16:26:53 <doron> when looking at any given VM 16:26:58 <itamar> since affinity is more than 1:1, could be 1:n, etc. 16:27:18 <doron> itamar: right, also :n// 16:27:22 <doron> n:n.. 16:27:46 <doron> ie- a vm may reference several affinity instances 16:27:54 <doron> which in turn reference other VMs. 16:28:02 <doron> or even networks 16:28:29 <sherold> scheduler API is going to get a workout on this one 16:28:39 <msivak> not necessarily 16:29:03 <doron> so I'd try to keep it simple if we so not want to solve equasions here 16:30:20 <msivak> doron: if a vm is part of a single group that references a list of other groups with defined affinity, we just create a scoring func that sums the numbers up based on a list of running vms on each host 16:30:45 <msivak> but the support in all the structures will touch a lot of apis.. 16:30:48 <doron> msivak: scoring is optimization. we may need a filter 16:31:10 <doron> anyway, 16:31:12 <sherold> msivak: while filtering out hosts that dont meet an affinity/anti rule 16:31:29 <sherold> which should be done first I'd think 16:31:34 <msivak> yeap 16:31:56 <doron> we'll work on a design which we can later discuss 16:32:18 <msivak> I was wondering about our cpu load representation 16:32:23 <msivak> I mentioned that in my part 16:32:33 <doron> msivak: ? 16:32:55 <msivak> currently we do not distinguish between old and lowly pentium I and strong supercomputer 16:33:09 <msivak> we just read cpu% and use that for scheduling 16:33:18 <msivak> is that right? 16:33:25 <doron> msivak: yeh this is a known issue many try to resolve 16:33:50 <doron> msivak: basically any platform tries to resolve it differently 16:33:56 <msivak> doron: all our hosts are linux based, /proc/cpuinfo gives you bogomips value 16:34:01 <doron> so VMware has one solution, ec2 has wnother and 16:34:13 <doron> microsoft has a third. 16:34:38 <doron> bogomips is nice but more an indication than somehting people would rely on 16:34:46 <doron> that;s whee bogo comes from. 16:34:59 <msivak> right, kernel computes it during startup 16:35:02 <doron> (that's there) 16:35:20 <msivak> but even if we hide it from the user, we could use it for scheduling (and host power management) 16:35:20 <doron> so I have a way to handle it but we'll need to discuss it seperatly. 16:35:47 <msivak> cpu%*bogomips = used/free power 16:36:22 <doron> msivak: this is an indication and not really accurate. What happens with numa? 16:36:31 <doron> you cannot really use it. 16:36:57 <msivak> but numa is memory, isn't it 16:37:11 <doron> msivak: numa cell is ram+cpu 16:37:28 <msivak> right, but currently we have separate cpu and memory filters 16:37:44 <doron> which we'll need to adapt to numa 16:37:47 <msivak> that we will have to change probably, but.. 16:37:55 <doron> but as long as it's simple we can handle it. 16:38:34 <doron> msivak: let's see the case in a different forum. ok? 16:38:38 <msivak> sure 16:38:43 <gchaplik_> thanks guys, I will send a meeting summary later on 16:38:50 <gchaplik_> safe drive 16:39:00 <gchaplik_> #endmeeting