API endpoint (either REST or Internal Morph) to get Network Domains?

[#1]

Hello,

I’m trying to figure out how I could best approach reading in the network-domain values a group has access to in Morpheus, but I can’t find any logical/good way.

The goal is to create a Dynamic Input dropdown box to use in Blueprints that would provide the user with domains associate with the Group they selected to build under (as a user can be a member of more than one group via their SAML group membership information).

My issue is I can’t seem to find any good way of of this as the ‘Morpheus API’ only lists “Networks”, which we don’t map the vCenter Port Group “Network” in Morpheus to a specific Domain as there is not a 1-to-1 relationship there between Portgroup/VLAN and IPAM DNS for us.

Looking over the API docs, I also don’t see a good way to query /network/domains and be able to search for only network-domains by group permission, as it looks like any REST input option I’d make would require credentials inserted there vs calling as the currently logged in user (am I wrong there?). But, even then, that would still pull in all network-domains that have any group the user is a member of, vs just specific one(s) where that group is granted permission.

Any hints, tips, tricks, etc around this would be greatly appreciated as I can’t find a good starting point to try to build out from.

This sort of is related to the ask/question in Populate a REST API Option List accessing Morpheus REST API using the apiAccessToken for user specific options...basically build your own Morpheus API Option List as well it seems, at least in terms of using the logged in users access token for the API call to filter if somehow querying based on the selected Group being built under is not possible.

Thanks!

[KoreyG]

Hello @rjr162,

I don’t see resourcePermission on domains, similar to what I see on other constructs, datastores for example:

{
    "id": 4,
    "name": "vsanDatastore",
    "zone": {
        "id": 1,
        "name": "VMware Cloud"
    },
    "type": "vsan",
    "freeSpace": 2359695804931,
    "online": true,
    "active": true,
    "visibility": "private",
    "tenants": [
        {
            "id": 1,
            "name": "Primary",
            "defaultStore": false,
            "defaultTarget": true
        },
        {
            "id": 3,
            "name": "Demo - Shared Tenant",
            "defaultStore": false,
            "defaultTarget": false
        }
    ],
    "resourcePermission": {
        "all": true,
        "sites": [],
        "allPlans": false,
        "plans": []
    }
}

I’d recommend making an Idea on our forums here to add that functionality to be able to see those permissions on API calls for domains.

Additionally, you may want to vote on this Idea, which is allowing variables in fields in Option Lists, similar to the link you provided:
https://discuss.morpheusdata.com/t/option-lists-url-and-header-fields-should-support-variables

You may want to provide your use case in there as well, if it seems related. In the link above, maybe using the users apiAccessToken is possible then, so it will list only what they have access to from their context.

Additionally, this is an idea you might vote on, which looks to extend the Morpheus API functionality further:
https://discuss.morpheusdata.com/t/input-data-sources

That said, in addition to what @Ollie_Phillips mentioned, you could also use the Configuration phase of a workflow to intercept the payload, make some more advances decisions, then modify it before it gets created. This would limit the use choosing the domain, just making the decision for them. Here are some example links:

• https://discuss.morpheusdata.com/t/configuration-phase-to-modify-requested-instance-volume-information-before-deployment

• https://discuss.morpheusdata.com/t/edit-instance-configuration-before-deployment

• https://discuss.morpheusdata.com/t/changing-the-instance-hostname-with-a-workflow-task

I hope this helps. If you need deeper assistance, I’d recommend opening a Technical Request as @Ollie_Phillips mentioned, which your account manager can assist with.

[Ollie-Phillips]

There’d need to be a selection hierarchy. A form would be best since it gives us access to some built in inputs.

The user in a group would need to pick in this order ( I think).

Pick Group they have access to - Morpheus forms input/control
Pick Cloud in Group - Morpheus forms input/control
Pick Network - Morpheus forms input/control
Pick Network Domain - Input based on option list, which filters on selected network ID via translation script.

Although I think I see the ask/proble, there’s a lot of info to unpack, in your post, so please consider submitting a technical request if your company has tokens.

[#4]

@Ollie_Phillips @kgawronski

I’ll see about the technical ask as this has been a fairly longstanding issue for us, as we’d really like to use Blueprints but can’t because of the domain selection.

The standard Instances → Provisioning has this option under the Advanced Settings → Domain (which handles the IPAM registration and the AD join if setup), but the Blueprints builder has no such reference (or does the Internal API call) This is where I’m trying to build out a replicated feature of the “Domain” selection as this was also a past suggestion forward, but I’m not sure that I can with what I can find.
Basically a user could select any “Network” in the normal Instances → Provisioning section, and then either the default domain we have that’s a generic “internal cloud service” DNS zone without AD join, or select a specific DNS/AD domain they’ve asked us to onboard on their behalf that lands their systems in AD in their requested units OU Path.

I’ll follow up on the technical request aspect of this.

Thanks!

– Ron

[KoreyG]

I think the technical request will be best route. The other option I think I can also provide is that you can create custom networks, which are associated to a parent network. This allows you have different configurations for the same network parent network, which each you could associate the needed domain. Depending on the complexity though, it may or may not fit the bill.