Config schema discussion

[waynew]

I've been kicking this around for a while - I don't have completely solid thoughts on the matter, so I figure it would be a good discussion point for here. I think that we want to use saltext.vmware as our top-level config option. So we might have something like:

salext.vmware:
    esxi:
        host: 203.0.113.42
        user: fnord@example.com
        password: CorrectHorseBatteryStaple

Alternatively, if we have profiles:

saltext.vmware:
    profile1:
        esxi:
            host: 203.0.113.99
            user: susanhilton@control.example.com
    profile2:
        vmc:
            host: ...
            

Does this seem like a reasonable layout to everyone? Is there something that I'm missing or forgetting here? In particular I'm thinking about how cloud profiles and proxy minions would work here as well, because those are the sorts of things that we'll want to support going forward. I can envision, for instance, using Salt to spin up vms in vCenter and then manage them as proxy minions. Or other vms would be managed as native minions.

I just want to make sure that we can provide this config data as seamlessly as possible.

[dmurphy18]

Don't forget delta-proxy too, proxy-minion should have it covered but want to keep delta-proxy in the loop too

[dfidler]

I keep meaning to push a SEP for this (but I keep getting distracted by my day job) but there are six things that I think are missing from salt, two of which I think are relevant here (bear with me if they are not immediately obvious):

1. Salt should be platform aware;

• modules should declare which platforms they work on and return a new status "failure_invalid_platform" (I won't go into the reasons for now)
• state writers should be able to define (in metadata/comments) which platforms their states run on
• the agent should validate states against their supported platforms ([FEATURE REQUEST] Define state file pre-requisites in metadata (instead of code) salt#58694)
• salt-proxy minions should return the a valid value for "platform" (instead of just "Proxy" - ie - oracle, mssql, esxi, vcenter)
• salt should issue warnings when modules don't declare a supported platform
• salt should issue warnings when state files don't declare supported platforms

The implications of this are huge for salt content.

2. All salt-minions should be like the "delta-proxy" such that

• A minion_id exists for the host os (which can be disabled)
• The minion can have "salt-proxyesque" sub-minions, with unique minion IDs
• The main minion object understands it's "platform" (windows, linux, oracle, mssql, aws, gcp, esxi, vcenter, napalm, etc)
• The minion handles platform checking (so I don't have to code it in Jinja2 in my state files - cuz that is just ugly
• The minion understands the targeting for each of its sub-modules and spawns processes to deal with jobs appropriately
• Spawns minimal processes to manage "work" (one call per operation, not one call per minion)
• The master can be configured to "auto accept all sub-minions" of an accepted parent minion

As you can imagine, I got really excited about the delta-proxy when I heard about it because it takes a big step toward this vision.

I had a quick discussion with Tom about this in early 2019 and his eyes went off into the distance and he said, "hmm.. the number of minions could increase exponentially" (I disagree btw, as we could be choosy about which platforms become first-class minions). Then we had to go to a meeting and the subject got dropped. But it's been bugging me for my entire time in working with salt.

Anyway, getting to the point....

If I extend that architectural pattern to this situation my "ideal" solution is a new vsphere "delta-proxyesque" minion (see "2", above) [that replaces the old salt-proxy minions], such that:

1. The admin configures the minion to talk to vsphere using standard proxy-minion conf methodologies (url, user/pass, etc)
2. New minion detects all relevant objects managed by vsphere and creates minion_ids for them (on startup, refreshed using something like saltutil.refresh_identities)
3. New minions are auto-accepted by the master (because the master trusts the parent minion's authority)
4. Removed minions are auto-removed from the master (so they are no longer targetable)
5. Grains are set on the esxi host minions with appropriate "cluster, datacenter, maintenance mode, etc" values set
6. Targeting is handled by the parent minion such that a target string gets converted into a "host filter" in the new SDDC modules (where applicable

Architecturally, this is very clean and the user experience is dead easy - simply configure the minion to talk to vSphere and everything else is managed for your. No management of separate url/endpoint/credentials for each for salt-proxy or delta-proxy. And each esxi host/cluster/datacenter/vcenter has an identity (per "2", above) and a clearly defined platform (per "1", above).

As I lament in #257, the SDDC modules were written to mirror the vSphere API which operates on multiple systems with a single call using filters. That is not how salt works - nor should it. Effective management and compliance reporting requires that managed assets have identity. So, to me, the minion (of whatever form) should be responsible for being the abstraction layer between those two completely different ways of working.

Most of the above is specifically related to the vSphere modules (and, I suspect, is less relevant to NSX-T, etc). But again, having specific delta-proxy minions for NSX-T, vROPs, etc, etc, etc shouldn't be that onerous (in fact, I think it's quite light) and it would give them identity inside of salt, and I think that is very important.

I realize that, as a solution, this is a much larger turn of the crank than defining profiles (per this discussion) because it redefines how we think of a minion. But having a separate project like the sddc modules might be a place to start developing the concept for eventual inclusion into the main salt project.

[abhi1693]

@waynew Today, I was working with single ESXi hosts and realised that even though the service_instance takes the profile name for esxi_host it is not being passed from any of the methods into service_instance. Therefore, the configuration is just for show as of today.

I'm thinking should we drop the extra key esxi_host and just make it simpler, something like

saltext.vmware:
    profile1:
        host: 203.0.113.99
        user: susanhilton@control.example.com
        password: ImAwesome
    profile2:
        host: 203.0.113.98
        user: susanhilton@control.example.com
        password: ImAwesome

How does it matter in this case to have an additional key to denote the list is for ESXIs. Our code does not differentiate either, it just needs a host, username and password to connect to.

If this seems feasible, I'll make the necessary changes today itself.

Otherwise, we need to modify the entire code to pass esxi_host to service_instance wherever necessary. This seems more error-prone to me being the change I have implemented.