Policies on machine type cancel out? #196966
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
🏷️ Discussion TypeQuestion Body
So no you can't? Set 2 & 4 core restriction for all repositories and 8 & 16 for 1 repo, Nothing can get 8 & 16 cores. The behaviour you want is inverted. Worse, if you set 2 & 4 cores for 1 repo, and 8 & 16 + for example, shorten idle timeout to 10min for that same repo. Those two cancel out and nothing at all is available. I can't have that right, but I've just done that in the UI and that's what happens. To make 2-4 cores everywhere but limit 8-16, I'll have to keep the 2-4 policy "selected repo" list constantly up to date, exclusive of the 8-16 selected repo list, and not use any "all repos" at all? |
Replies: 2 comments
Yeah, your understanding seems correct from how the policy system currently works. The policies are combined together instead of one overriding another. So if you create an organization wide policy that only allows 2 and 4 core machines, then a repository specific policy cannot later allow 8 and 16 core machines for a certain repo. Repository policies can only make things more restrictive, not less restrictive. The same thing explains why your second setup results in no machines being available at all. If one policy allows only 2 and 4 core machines, while another policy for the same repo allows only 8 and 16 core machines with a different timeout, there is no overlap between the two policies. Since nothing satisfies both conditions, Codespaces ends up with no valid machine types. So unfortunately, if you want most repositories to use 2 and 4 core machines, but a few repositories to have access to 8 and 16 core machines, it looks like you cannot do that using a single organization wide restriction. You would instead need to manage separate repository scoped policies and keep those repo lists maintained manually. It definitely feels counterintuitive because many policy systems support exceptions or priority order, but this implementation seems to work as an intersection of restrictions only. |
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Yeah, your understanding seems correct from how the policy system currently works. The policies are combined together instead of one overriding another.
So if you create an organization wide policy that only allows 2 and 4 core machines, then a repository specific policy cannot later allow 8 and 16 core machines for a certain repo. Repository policies can only make things more restrictive, not less restrictive.
The same thing explains why your second setup results in no machines being available at all. If one policy allows only 2 and 4 core machines, while another policy for the same repo allows only 8 and 16 core machines with a different timeout, there is no overlap between the two poli…