neoave / mrack

Multicloud use-case based multihost async provisioner for CIs and testing during development
Apache License 2.0
11 stars 14 forks source link

feat: Support size definition in metadata #89

Closed Tiboris closed 3 years ago

Tiboris commented 3 years ago

feat: Support size definition in metadata Signed-off-by: Tibor Dudlák tdudlak@redhat.com

pvoborni commented 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.