Closed Tiboris closed 3 years ago
Hi,
This falls into category of: provider specific configuration in a host configuration. It makes it difficult to simply switch a provider to something else as other providers might not have a concept of flavor. In other words it goes against philosophy of the project: that we have a common configuration in provisioning config and job metadata describes it from application perspective. In the end more difficult to run the same job in different environments.
Better approach would be to identify why we need the change of flavor (the app perspective) and model it in job metadata in a way that it supports switching between provider.
E.g. we need a bigger machine, that can mean e.g.:
Atm it is modeled through group(s).
Before Mrack, the limitation was that only one group per host was possible. Now mrack can have multiple groups. The only issue is that we don't know which group is the one to pick for flavor.
But instead a 'flavor', I can imaging that we introduce a new host attribute called 'size'. It reflects the app usage.
So e.g. we can have a provisioning config which has:
openstack:
flavors:
ipaserver: m1.medium
ipaclient: m1.micro
large: m1.large
huge: m1.xlarge
aws:
flavors:
ipaserver: t1.medium
ipaclient: t1.micro
large: t1.large
huge: t1.xlarge
Then job metadata file can have:
domains:
name: foo.bar
hosts:
- name: hugeserver.foo.bar
group: ipaserver
size: huge
- name: normalserver.foo.bar
group: ipaserver
This will work even with provider switching.
That said, I'm not against having a support for per-provider override in Mrack. But I'd rather if it was more explicit and really per-provider and that the it would have general build-in support. My initial ideas, which were not yet implemented were that we will have 3 sources of configuration for a host - the closer the higher priority:
I can dump it into a design page if needed.
feat: Support size definition in metadata Signed-off-by: Tibor Dudlák tdudlak@redhat.com