TL;DR · Key Takeaways
- A project is a real team inside a tenant: who is in it, what they can deploy, and how much they can consume.
- Organization administrators create projects, manage members, and set resource limits. Access is governed by predefined roles.
- Projects hold namespaces, which draw quota from the organization’s region quota and carry CPU, memory, and storage limits.
- A namespace class is a reusable template for those limits, VM classes, storage classes, and content libraries. Build classes, do not hand-tune every namespace.
- A project constraint is a key:value governance tag that steers a deployment toward or away from specific cloud zones. It is how you enforce placement.
If the tenant is the wall, the project is the room. The tenant isolates a business unit from everyone else; the project is where a real team inside that business unit gets a bounded slice to work in. Who is in the room, what they are allowed to build, and how much they can use are all project decisions. This is the layer where multi-tenancy stops being architecture and starts being something a team logs into on Monday morning.
What a project is, and what it holds
A project represents a real team in charge of development or operations. It is created and run by organization administrators, who add the members, assign roles, and set the resource limits the team works within. Inside a project sit one or more namespaces, and the namespace is where the actual capacity lives: it draws its quota from the organization’s region quota and carries limits on CPU, memory, and storage. So the chain is tenant, then project, then namespace, then real cluster capacity, and a deployment lands at the bottom of that chain.
Why you should care about getting this layer right: the project is where over-provisioning and noisy-neighbour problems are prevented or created. A project with no real limits is a team that can consume the whole tenant’s quota, and the first you hear of it is another team’s deployment failing. Set the limits when you create the project, sized to what the team actually needs plus headroom, and the platform does the policing for you instead of you doing it after an incident.
Members and roles
Access inside a project is governed by predefined roles, and the good news for anyone coming from Aria Automation is that the Service Broker and Assembler role model is unchanged underneath, so the access patterns you know still apply. The organization administrator adds members to a project and gives each the role their job needs: someone who authors templates is not the same as someone who only requests from the catalog, and the roles reflect that.
| Who | Does what | Lives in |
|---|---|---|
| Organization administrator | Creates projects, manages members, sets limits | The tenant |
| Template author | Builds and maintains cloud templates | Assembler |
| Consumer | Requests catalog items, manages own deployments | Service Broker |
What I tell clients about roles: grant the least that lets someone do their job, and drive membership from directory groups wherever you can. A project that maps a single group to a single role is a project you can reason about; a project with a dozen individually-added users and ad-hoc roles is one you will be untangling during an audit. The roles are simple on purpose. Keep your use of them simple too.
Resource limits and namespace classes
A namespace carries the limits, and you do not want to hand-tune them one namespace at a time. That is what a namespace class is for: a reusable template that defines CPU, memory, and storage limits, the VM classes and storage classes available, and content libraries. You build a small set of classes, say small, standard, and large, and stamp namespaces from them. When you need to deviate, an organization administrator can override the class limits at namespace creation, so the template is a default, not a straitjacket.
Namespace limits are satisfied from capacity in one or more cloud zones, and a zone is one or more vSphere clusters providing compute, memory, and storage. When you create a namespace you choose which zones it can use, which is your first lever on placement: a namespace restricted to zone-a will never land work in zone-b. Build the classes thoughtfully and most of your resource governance is done before a single team logs in.
# Namespace class: a reusable template (example)
namespace_class:
name: standard
limits:
cpu: 20 # vCPU ceiling
memory: 64Gi
storage: 500Gi
zones: [zone-a, zone-b] # where namespaces from this class may run
# Project constraint: a key:value governance tag (example)
constraints:
- key: env
value: prod
hard: true # MUST place on a cloud zone tagged env:prod
# A hard constraint blocks placement that does not match; a soft one only prefers it.Constraints: governance that steers placement
This is the part teams underuse, and it is the most powerful. A project constraint is a key:value tag that acts as a governance definition: it declares what resources a deployment request in the project should consume or avoid across the project’s cloud zones. Tag your cloud zones, for example env:prod or compliance:pci, then add a matching constraint to the project, and the platform refuses to place a deployment anywhere that does not match. That is how you keep a production project off development capacity, or keep regulated workloads on the only zones cleared for them, without trusting anyone to choose correctly.
Worked example
A finance tenant has two projects, dev and prod. You build two namespace classes: standard at 20 vCPU, 64Gi memory, 500Gi storage, and large at 64 vCPU, 256Gi, 2Ti. The dev project gets standard namespaces on zones tagged env:dev; the prod project gets large namespaces on zones tagged env:prod, plus a hard constraint env:prod. Now a developer cannot accidentally deploy a test workload onto production capacity, because the constraint refuses it, and prod cannot quietly balloon, because the namespace class caps it. Two classes and one constraint per project, and most of your day-to-day governance is automatic.
Designing namespace classes that scale
The single highest-leverage thing you do at this layer is design a small, deliberate set of namespace classes, because every project you ever create draws from them. Think of a class as a stamp: define it once and press it out across projects and tenants. Three classes, small, standard, and large, cover most estates. Resist the pull toward a class per team, because a catalogue of near-identical classes is the same maintenance burden as hand-tuning namespaces, just relocated.
Two design habits keep this clean as you grow. First, treat the per-namespace override as the exception it is meant to be. The ability for an organization administrator to override class limits at creation is there for the genuine one-off, the team that truly needs more, not as a substitute for thinking about your class sizes. Every override you make is a namespace that no longer tracks its class, so when you tune the class later, that one does not move with the others. A handful of overrides is fine; a habit of them means your classes are wrong and you should fix the classes.
Second, plan capacity at the zone level, not the namespace level. Because namespace limits are satisfied from one or more cloud zones, the question that actually matters is whether the zones behind a class have the headroom to honour every namespace stamped from it. The mistake teams make is sizing classes generously, stamping them widely, and only discovering at deploy time that the zones cannot back the sum of the limits they promised. Add up what your classes commit, compare it to real zone capacity, and leave margin. A namespace class is a promise; the cloud zone is what keeps it.
My Take
Projects are where a tenant becomes usable, so spend the design time here. My recommendation: model projects on real teams and environments, not on the org chart; drive membership from directory groups mapped to the least role that works; standardise on a small set of namespace classes rather than bespoke limits per namespace; and use constraints, backed by zone tags, to make placement a policy the platform enforces instead of a convention people are asked to honour. Build the classes and constraints once, well, and every project you stamp out afterward inherits sane limits and safe placement for free. That is the difference between a self-service platform that scales and one that becomes a queue of exceptions on your desk.
Next we connect the platform to real infrastructure: cloud accounts and the vCenter and NSX integrations underneath everything we have built. For the tenancy frame around projects, revisit Part 7 on tenant organizations. How many namespace classes do you run, and has constraint-based placement saved you from a bad deploy? Tell me in the comments.
Previous: Part 7, tenant organizations. Next: Part 9, cloud accounts and integrations (coming soon). Up: VCF Automation Guide (pillar).
References
- Managing Projects in VCF Automation (Broadcom TechDocs)
- Project Constraints and Custom Properties (Broadcom TechDocs)
- Infrastructure Policies in VCF Automation 9.1 (VCF Blog)
About The Author
