[affinity] Allow listing affinity/anti-affinity groups per-instance

[smklein]

Part of #7614

[david-crespo]

This will make for a great Affinity tab on the instance page in the console.

[david-crespo]

WHAT IS THIS BEAUTIFUL API

[smklein]

a hackery of query parameter appending for the affinity tests... but feel free to re-use it, if you want!

[david-crespo]

Should this (also or instead) check list children on projects since the groups are children of the project? I think that check is implied by this check because anyone with viewer+ on the project has list children on the project and the instance, but that's sort of incidental. It might be better if this check was more direct.

omicron/nexus/auth/src/authz/omicron.polar

Lines 178 to 195 in 0c92213

	resource Project {
	permissions = [
	"list_children",
	"modify",
	"read",
	"create_child",
	];
	roles = [ "admin", "collaborator", "viewer" ];
	# Roles implied by other roles on this resource
	"viewer" if "collaborator";
	"collaborator" if "admin";
	# Permissions granted directly by roles on this resource
	"list_children" if "viewer";
	"read" if "viewer";
	"create_child" if "collaborator";
	"modify" if "admin";

omicron/nexus/authz-macros/src/lib.rs

Lines 372 to 395 in 0c92213

	// If this resource is directly inside a Project, we only need to define
	// permissions that are contingent on having roles on that Project.
	(PolarSnippet::InProject, "Project") => format!(
	r#"
	resource {} {{
	permissions = [
	"list_children",
	"modify",
	"read",
	"create_child",
	];
	relations = {{ containing_project: Project }};
	"list_children" if "viewer" on "containing_project";
	"read" if "viewer" on "containing_project";
	"modify" if "collaborator" on "containing_project";
	"create_child" if "collaborator" on "containing_project";
	}}
	has_relation(parent: Project, "containing_project", child: {})
	if child.project = parent;
	"#,
	resource_name, resource_name,
	),

[david-crespo]

I see we do the same for listing instance disks, which are directly analogous from an authz POV. Seems fine?

omicron/nexus/src/app/instance.rs

Lines 1410 to 1422 in 0c92213

	/// Lists disks attached to the instance.
	pub(crate) async fn instance_list_disks(
	&self,
	opctx: &OpContext,
	instance_lookup: &lookup::Instance<'_>,
	pagparams: &PaginatedBy<'_>,
	) -> ListResultVec<db::model::Disk> {
	let (.., authz_instance) =
	instance_lookup.lookup_for(authz::Action::ListChildren).await?;
	self.db_datastore
	.instance_list_disks(opctx, &authz_instance, pagparams)
	.await
	}

[smklein]

Gonna leave this as-is -- we can revisit both together, but keeping them uniform seems fine for now?

[david-crespo]

I typed this up

Maybe this is just necessary to make the compiler happy, but what does it mean to paginate by either name or ID here? Is it possible to select one or the other?

but I answered my own question. Putting it here for posterity: the use of PaginatedByNameOrId in the query params on the endpoint means this takes a sort_by=NameOrIdSortMode param that lets you specify sort by ID, name asc, or name desc.

[david-crespo]

Look great, could possibly use one small authz tweak.