Am 25.04.25 um 15:25 schrieb Daniel Kral:
> On 4/25/25 14:25, Fiona Ebner wrote:
>> Am 25.04.25 um 10:36 schrieb Daniel Kral:
>>> On 4/24/25 12:12, Fiona Ebner wrote:
>>> As suggested by @Lukas off-list, I'll also try to make the check
>>> selective, e.g. the user has made an infeasible change to t
On 4/25/25 14:25, Fiona Ebner wrote:
Am 25.04.25 um 10:36 schrieb Daniel Kral:
On 4/24/25 12:12, Fiona Ebner wrote:
As suggested by @Lukas off-list, I'll also try to make the check
selective, e.g. the user has made an infeasible change to the config
manually by writing to the file and then wants
Am 25.04.25 um 10:36 schrieb Daniel Kral:
> On 4/24/25 12:12, Fiona Ebner wrote:
>> Am 25.03.25 um 16:12 schrieb Daniel Kral:
>>> | Canonicalization
>>> --
>>>
>>> Additionally, colocation rules are currently simplified as follows:
>>>
>>> - If there are multiple positive colocation rules w
Thanks for the review, Fiona!
I have some comments left, one of them is about the last comment about
how to migrate HA groups to location rules to give a better illustration
why I'd like to allow multiple location rules in the end, hope we're
able to do this.
On 4/24/25 12:12, Fiona Ebner wr
Am 25.03.25 um 16:12 schrieb Daniel Kral:
> | Canonicalization
> --
>
> Additionally, colocation rules are currently simplified as follows:
>
> - If there are multiple positive colocation rules with common services
> and the same strictness, these are merged to a single positive
> col
Am 25.03.25 um 17:47 schrieb Daniel Kral:
> On 3/25/25 16:12, Daniel Kral wrote:
>> Colocation Rules
>>
>>
>> The two properties of colocation rules, as described in the
>> introduction, are rather straightforward. A typical colocation rule
>> inside of the config would look like t
Am 01.04.25 um 11:39 schrieb Daniel Kral:
> On 4/1/25 03:50, DERUMIER, Alexandre wrote:
>> my 2cents, but everybody in the industry is calling this
>> affinity/antiafifnity (vmware, nutanix, hyperv, openstack, ...).
>> More precisely, vm affinity rules (vm<->vm) vs node affinity rules
>> (vm->no
On April 1, 2025 11:39 am, Daniel Kral wrote:
> On 4/1/25 03:50, DERUMIER, Alexandre wrote:
>> Small feature request from students && customers: they are a lot
>> asking to be able to use vm tags in the colocation/affinity
>
> Good idea! We were thinking about this too and I forgot to add it to t
On 4/1/25 03:50, DERUMIER, Alexandre wrote:
my 2cents, but everybody in the industry is calling this
affinity/antiafifnity (vmware, nutanix, hyperv, openstack, ...).
More precisely, vm affinity rules (vm<->vm) vs node affinity rules
(vm->node , the current HA group)
Personnally I don't care,
--- Begin Message ---
>>I currently implemented the colocation rules to put a constraint on
>>which nodes the manager can select from for the to-be-migrated
>>service.
>>So if users use the static load scheduler (and the basic / service
>>count
>>scheduler for that matter too), the colocation ru
Hi Daniel,
thanks for working on this !
>>I chose the name "colocation" in favor of affinity/anti-affinity,
>>since
>>it is a bit more concise that it is about co-locating services
>>between
>>each other in contrast to locating services on nodes, but no hard
>>feelings to change it (same for an
On 3/25/25 16:12, Daniel Kral wrote:
Colocation Rules
The two properties of colocation rules, as described in the
introduction, are rather straightforward. A typical colocation rule
inside of the config would look like the following:
colocation: some-lonely-services
ser
This RFC patch series is a draft for the implementation to allow users
to specify colocation rules (or affinity/anti-affinity) for the HA
Manager, so that two or more services are either kept together or apart
with respect to each other in case of service recovery or if
auto-rebalancing on service
13 matches
Mail list logo
