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