Community
Participate
Working Groups
This bug is to track the API discussion for the IGoverner interface to be included as part of P2. The base operations that I suggest to support include two aspects, the first is to handle advice to be consumed by the user interface and then the actual restrictions being implemented in coordination between the Governer and the Engine. Starting the with hard restrictions, these are the operations that the Governer should have influence over: - Can the engine provide any operations on the given profile - Can the engine perform the selected list of operations (already expanded by the director) - Can the engine consume software from the given meta/artifact repository(ies) For the user interface, we may need the Governer to be able to provide a more "friendly" usage for display to the end user. The operations the Governer should be able to advise on should include: (Note that these are hints, not necessarily hard constraints, just to avoid the user attempting to perform operations and then have the engine reject it later.) - Can a given IU be installed, uninstalled, or upgraded - Is the given profile modifiable by the end-user - Can the end-user register an additional meta/artifact repository? I'm also looking for the IGoverner API I wrote up this spring after the Provisioning Workshop but wanted to put in this placeholder to begin discussions regardless of finding that API.
For background, the idea of the Governer is to have it registered into the Profile similar to a security manager so that the Governer will be involved with any operations performed on the profile. This allows a provisioning system built on P2 to provide extra constraints beyond those directly handled by P2. At the Equinox Summit, we discussed a series of options and while the governer does have overlaps with general security, this is a special case where an entity needs to be able to have flexibility over vetoing given operations.
The pedantic side of me is driving this nipping in the bud... p2==p2 not P2 Governor should be Governor not Governer. Governer is both incorrectly spelled (google "definition:governer") and does not match are configuratOR, manipulatOR, marvin the martian naming convention.
> does not match are configuratOR, manipulatOR, marvin the martian naming convention. I feel compelled to point out that by our marvin the martian naming, it would have to be called "the governator" (google that one, for a laugh) ;)
Created attachment 80277 [details] Patch exploring governor's idea I have started looking into this area to get a feel for how much work will be needed here. Following Tim's remark: > "the idea of the Governer is to have it registered into the Profile similar to a security manager so that the Governer will be involved with any operations performed on the profile.", I have prototyped a governor API and a simple implementation reusing the concept of Permission. I like it because it keeps the API very simple and allows for extensibility since new permissions can be added without changing the governor. The attached code contains an InstallableUnitPermission whose goal is to check if the addition / removal / update of an IU is authorized but I can easily see the addition of a RepositoryPermission to control the access to artifact and metadata repos. The aspects I don't know how to handle quite yet are: - how to the add / remove permissions to the governor and does it needs to be API? - is the API on governor to check permission good enough for UI needs? For example do we need an API that returns a boolean or status instead of throwing an exception? Note that the patch does not cover the "advisor" part of the governor's behavior.
Created attachment 80278 [details] Patch exploring governor's idea I have started looking into this area to get a feel for how much work will be needed here. Following Tim's remark: > "the idea of the Governer is to have it registered into the Profile similar to a security manager so that the Governer will be involved with any operations performed on the profile.", I have prototyped a governor API and a simple implementation reusing the concept of Permission. I like it because it keeps the API very simple and allows for extensibility since new permissions can be added without changing the governor. The attached code contains an InstallableUnitPermission whose goal is to check if the addition / removal / update of an IU is authorized but I can easily see the addition of a RepositoryPermission to control the access to artifact and metadata repos. The aspects I don't know how to handle quite yet are: - how to the add / remove permissions to the governor and does it needs to be API? - is the API on governor to check permission good enough for UI needs? For example do we need an API that returns a boolean or status instead of throwing an exception? Note that the patch does not cover the "advisor" part of the governor's behavior.
Pascal, in going through the patch, it does address most of the needs at an API level. Thanks for putting together a start at an implementation. I agree that using a Permission structure provides greater flexibility. In the current API, how would you imagine the Governor getting access to information such as the Profile that the permission request is particular to? It's likely that the Governor will need context including the profile and potentially associated user credentials to be able to fully determine whether a given operation is valid. Also, the current InstallableUnitPermission is structured around a given IU being installed. I could imagine scenarios whereby a Governor will need the full context of the change being performed prior to making a determination on validity for what is being done. To that end, the same Governor / Permission API would allow a more complex Permission object that would represent the changes of the transaction vs. a single operation, the new API being something like ProvisioningPlanPermission. For this to work though, we need to make sure that the base requests from the Planner / Director / Engine provide sufficient context to the Governor for a given operation to be successful. Would it make sense to have both the InstallableUnitPermission as well as ProvisioningPlanPermission as part of the default support? With these two, I believe the Governor would be able to provide context in both scenarios. Regarding the second (PPP), the Planner could pass the proposed ProvisioningPlan to the Governor prior to returning it to the caller. So I see two changes that would allow handling the above scenarios: 1. Add Profile parameter to IGovernor API (or alternate GovernorContext object for future extensibility) 2. Create a ProvisioningPlanPermission call to Governor triggered off of the Planner Once these calls are updated, we could then look into where the right places are to trigger the calls -- such as calling from the Engine as well as the Planner to see that a given IU can be modified as part of a p2 operation.
>- is the API on governor to check permission good enough for UI needs? For >example do we need an API that returns a boolean or status instead of throwing >an exception? I looked at the patch. I like that the governance exception is handled and reported in the status returned by the planner. I would want to see the exception included in the status, though, and a better message ("not allowed" vs. "couldn't install.") I agree with Tim that we might want to be able to check permissions on the resolved operations, and if the rejection is at the operation level, I would expect that the returned plan included the operations as well as the status saying it was rejected and the originating exception. As for use cases where we call the governor from the engine. I can't think of any on the UI side, I would hope that the planning phase handles this when possible. If there are use cases where engine actions, etc. might end up rejecting the install, I would expect to see that returned as a failing status from the perform call, along with the originating exception. The main thing for me is that the returned statuses, status codes, messages, exceptions, etc. look unform whether they come from a director install, a plan/perform combo, or an engine perform failure. That way my error code path for reporting what happened to the user can be the same.
> In the current API, how would you imagine the Governor getting access to > information such as the Profile that the permission request is particular to? The profile would be implicit since, as suggested in comment # , the governor would be associated to a profile. In terms of implementation, the governor will have a profile slot. > potentially associated user credentials I think this is an implementation detail of the governor on how it determines / stores the permissions that needs to be applied. It seems to me that there is an intersection here with the role based security work that is going on in the equinox security incubator. > I could imagine scenarios whereby a Governor will need the full context of the > change being performed prior to making a determination on validity for what is > being done. I agree with this however I have difficulties seeing how the governor gets access to the context and I'm not thrilled by the idea that it is something that is being passed around by everyone. Ideally I would like the governor to be omniscient. What do you think of having every operation building up the context actually indicating this to the governor? I have updated the patch to include an example of this. However we need to decide what is the shape of the "API" of this context object and how it relates to the ProvisioningPlan. >Would it make sense to have both the InstallableUnitPermission as well as ProvisioningPlanPermission as part of the default support? With these two, I The permission provided was just a simple example to prove the point and depending on how things evolve it probably makes sense to have the ProvisioningPlanPermission as well.
Created attachment 80457 [details] New patch taking into considerations comments
Created attachment 85495 [details] Updated patch with current code base The following patch is updated based on Pascal's last patch but is now consistent with the current code base.
> What do you think of having every operation building up the > context actually indicating this to the governor? This makes sense to me. In looking at the current code, I think this is actually enough for what we would want and gives flexibility in the future for additional permission actions. If we update the patch to look for a registered IGovernor service and if it finds one, use it in the planner, I think we are good at this level. What did we decide with regards to the engine calling into the governor as well? Would we just have another permission that is a bit lower level that the engine would trigger on?
Regarding comment #7, we will still need to provide more consistent error handling to address Susan's needs for presentation in the UI.
