Should IPM itself be namespace specific?

[isc-rsingh]

• Realize it by creating package mapping of %IPM package to the target namespace's routine database

• Let the user choose whether to install IPM during namespace configuration - requires an update to Config.Namespaces() logic

• Will be installed from the manifest file that shipped with the IRIS instance - can still be installed via user's loading the manifest file and/or upgrade from registry repository

• (Assuming IPM itself will be namespace specific) In old versions of IRIS, IPM can still be loaded manually into the namespace. Though upon namespace configuration, there will be no option to automatically install IPM.

• Pros:

  • Each namespace can be treated as it’s own application and work independently of other namespaces
  • Support deploying different versions of a package in different namespaces which have different dependencies on versions of IPM
  • Strong security
  • If user don't want, they don't need to install IPM to a specific namespace

• Cons:

  • Very rare use cases right now based on Community PM of needing separate IPM versions - more solid use cases?
  • Additional work for user to choose whether or not to install; seems unnecessary

[daimor]

I would say, that we have to encourage developers to configure and use IRIS the right way.

• Application per IRIS instance
  • At least, do not mix up different types of environments on the same instance
• Production, Staging Development, or any other types of environments, should have its own instance
• Do not use IPM in any form in the Production environment at all
  • Yes, the production environment should have only the final code, required for the application itself, and IPM is not needed there

I see no reason, to have a namespace-specific Package Manager, at all. It will add more pain for developers of IPM and for end-users developers

[gjsjohnmurray]

Given security constraints, there is no way to make IPM not namespace-specific (cannot use %ALL and cannot keep files in IRISSYS)

Please elaborate on this comment by @isc-kiyer

[isc-kiyer]

As I said in the other thread for "Map %IPM to all namespaces", %ALL has some inherent issues so shall not be used. Any code in IRISSYS gets escalated privileges to do role escalation and such code should be minimized for best security.

[adaptun]

As far as I know only code in specific packages in IRISSYS can escalate roles, not all code in IRISSYS

[isc-kiyer]

All code in IRISSYS can escalate roles. That is the primary purpose of putting code in IRISSYS.

[bg-ssh]

My vote is that IRIS instance should only have a single ZPM version.

To add to Raj's considerations above, there are few more issues with multi-versioned ZPM

1. zpm command and $zpm function are global. Version mismatch might make them unstable or unusable.
2. updating ZPM itself for the whole instance seems to become way more complex than it should be
3. it's still unclear how people will decide which namespace should have which ZPM version,which ZPM to activate when adding a new namespace, should we upgrade all namespaces when upgrading ZPM or only one, etc etc etc

Having said that, there might also be a reason to mark individual namespaces "zpm-active" or not similar to how we do "Ensemble activation", for me the Ensemble thing was always only a source of problems and not advantages but if there are compelling reasons to why a namespace might not want ZPM in it I'm happy to hear them.

But overall, my vote would be to make ZPM if not built-in then more Ensemble-like -- we don't allow multiple Ensemble versions on one instance and nor should we allow the same for ZPM

[eduard93]

What does IPM being namespace specific entails?

Does it mean each namespace has a separate version of the IPM code? Or does that mean each namespace have a separate list of installed IPM packages/package versions?

[evshvarov]

Namespace-specific IPM means the opportunity to have different IPM versions in different namespaces across one IRIS system. In both system-wide and namespace-specific cases, a namespace can have a different set of installed packages, as it is now with ZPM.

…

On Fri, Jun 17, 2022 at 3:52 PM Eduard ***@***.***> wrote: What does IPM being namespace specific entails? Does it mean each namespace has a separate version of the IPM code? Or does that mean each namespace have a separate list of installed IPM packages/package versions? — Reply to this email directly, view it on GitHub <#322 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVHEP2KO2CQ3SYAPZW7VQTVPRRG7ANCNFSM5YYD7VFA> . You are receiving this because you are subscribed to this thread.Message ID: <intersystems-community/zpm/repo-discussions/322/comments/2971071@ github.com>

[eduard93]

In that case, I'm not sure we should allow different IPM versions on one instance. As we update interoperability and system code, we should update the IPM code (With a caveat that the user can update the IPM code himself if desired).
In that scenario (one IPM per system but enabled only for some namespaces), we can still get ost of the pros:

• Each namespace can be treated as its own application and work independently of other namespaces
• Support deploying different versions of a package in different namespaces AS LONG AS they support the current version of IPM, which is usually the case as the new IPM version is backward compatible. Sure it might offer some new functions unavailable on old IPM versions, but old packages still work with newer IPM versions.
• Strong security (everything on the latest IPM version looks better security-wise)
• If users don't want, they don't need to install IPM to a specific namespace (still true)

But updating scenario, in that case, is much simpler - as we don't need to iterate over (or remember) specific namespaces.

[evshvarov]

I second Sergey's opinion on treating IPM as Ensemble in IRIS now. People got used to Ensemble living in ENSLIB so we'd have IPM of some version across the system that could be upgraded in this IPM namespace (is it possible?) and being used from other namespaces where it is installed. On Fri, Jun 17, 2022 at 5:22 PM Евгений Шваров ***@***.***> wrote:

…

Namespace-specific IPM means the opportunity to have different IPM versions in different namespaces across one IRIS system. In both system-wide and namespace-specific cases, a namespace can have a different set of installed packages, as it is now with ZPM. On Fri, Jun 17, 2022 at 3:52 PM Eduard ***@***.***> wrote: > What does IPM being namespace specific entails? > > Does it mean each namespace has a separate version of the IPM code? Or > does that mean each namespace have a separate list of installed IPM > packages/package versions? > > — > Reply to this email directly, view it on GitHub > <#322 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAVHEP2KO2CQ3SYAPZW7VQTVPRRG7ANCNFSM5YYD7VFA> > . > You are receiving this because you are subscribed to this thread.Message > ID: <intersystems-community/zpm/repo-discussions/322/comments/2971071@ > github.com> >

[isc-mstolwyk]

There should only be one version of IPM per IRIS instance. It is reasonable to expect this tool to work identically regardless of namespace. Also consider the case where a security update has been made. Who would want to unknowingly execute a vulnerable API? No, everyone would want to update the instance once and benefit from the fix in all namespaces.

[isc-rsingh]

This topic is now closed with the decision:
IPM itself should NOT be namespace specific. Only one version of IPM will exist per instance. (unless of course the administrator manually creates a custom install/mapping configuration, which we cannot control)