as the modules are now being loaded onto the main interpreter (see
ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543
Signed-off-by: Nizamudeen A <nia@redhat.com>

After PR ceph#66244, all mgr modules run inside the same Python interpreter.
That means they also share the same logging subsystem.
Previously, each module attached its handlers to the root logger. In practice,
whichever module initialized logging last effectively “owned” the root logger,
and log messages from other modules could end up attributed incorrectly.

This change scopes logging per module. Each module now registers its handlers
on a dedicated logger named after the module itself, with propagate=False to avoid
leaking messages into the root logger.

Now, the getLogger() default (no args) returns the module's named logger
rather than the root logger. This ensures self.log routes correctly.

Fixes: https://tracker.ceph.com/issues/74848
Signed-off-by: Nitzan Mordechai <nmordec@ibm.com>

After PR ceph#66244, all mgr modules run inside the same Python interpreter.
That means they also share the same logging subsystem.
Previously, each module attached its handlers to the root logger. In practice,
whichever module initialized logging last effectively “owned” the root logger,
and log messages from other modules could end up attributed incorrectly.

This change scopes logging per module. Each module now registers its handlers
on a dedicated logger named after the module itself, with propagate=False to avoid
leaking messages into the root logger.

Now, the getLogger() default (no args) returns the module's named logger
rather than the root logger. This ensures self.log routes correctly.

Fixes: https://tracker.ceph.com/issues/74848
Signed-off-by: Nitzan Mordechai <nmordec@ibm.com>

* refs/pull/66244/head:
	mgr/Gil.cc: simplify Gil(), ~Gil()
	mgr/Gil.cc: do not use PyGILState_Check()
	mgr: add mgr_subinterpreter_modules config
	python-common/.../service_spec: implement ServiceSpec.__getnewargs__ to allow unpickle to work correctly
	mgr: serialize python objects sent between subinterpreters via remote

After PR ceph#66244, all mgr modules run inside the same Python interpreter.
That means they also share the same logging subsystem.
Previously, each module attached its handlers to the root logger. In practice,
whichever module initialized logging last effectively “owned” the root logger,
and log messages from other modules could end up attributed incorrectly.

This change scopes logging per module. Each module now registers its handlers
on a dedicated logger named after the module itself, with propagate=False to avoid
leaking messages into the root logger.

Now, the getLogger() default (no args) returns the module's named logger
rather than the root logger. This ensures self.log routes correctly.

Fixes: https://tracker.ceph.com/issues/74848
Signed-off-by: Nitzan Mordechai <nmordec@ibm.com>

as the modules are now being loaded onto the main interpreter (see
ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543
Signed-off-by: Nizamudeen A <nia@redhat.com>

After PR ceph#66244, all mgr modules run inside the same Python interpreter.
That means they also share the same logging subsystem.
Previously, each module attached its handlers to the root logger. In practice,
whichever module initialized logging last effectively “owned” the root logger,
and log messages from other modules could end up attributed incorrectly.

This change scopes logging per module. Each module now registers its handlers
on a dedicated logger named after the module itself, with propagate=False to avoid
leaking messages into the root logger.

Now, the getLogger() default (no args) returns the module's named logger
rather than the root logger. This ensures self.log routes correctly.

Fixes: https://tracker.ceph.com/issues/74848
Signed-off-by: Nitzan Mordechai <nmordec@ibm.com>

as the modules are now being loaded onto the main interpreter (see
ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543
Signed-off-by: Nizamudeen A <nia@redhat.com>

After PR ceph#66244, all mgr modules run inside the same Python interpreter.
That means they also share the same logging subsystem.
Previously, each module attached its handlers to the root logger. In practice,
whichever module initialized logging last effectively “owned” the root logger,
and log messages from other modules could end up attributed incorrectly.

This change scopes logging per module. Each module now registers its handlers
on a dedicated logger named after the module itself, with propagate=False to avoid
leaking messages into the root logger.

Now, the getLogger() default (no args) returns the module's named logger
rather than the root logger. This ensures self.log routes correctly.

Fixes: https://tracker.ceph.com/issues/74848
Signed-off-by: Nitzan Mordechai <nmordec@ibm.com>

as the modules are now being loaded onto the main interpreter (see
ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543
Signed-off-by: Nizamudeen A <nia@redhat.com>

After PR ceph#66244, all mgr modules run inside the same Python interpreter.
That means they also share the same logging subsystem.
Previously, each module attached its handlers to the root logger. In practice,
whichever module initialized logging last effectively “owned” the root logger,
and log messages from other modules could end up attributed incorrectly.

This change scopes logging per module. Each module now registers its handlers
on a dedicated logger named after the module itself, with propagate=False to avoid
leaking messages into the root logger.

Now, the getLogger() default (no args) returns the module's named logger
rather than the root logger. This ensures self.log routes correctly.

Fixes: https://tracker.ceph.com/issues/74848
Signed-off-by: Nitzan Mordechai <nmordec@ibm.com>

as the modules are now being loaded onto the main interpreter (see
ceph/ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543
Signed-off-by: Nizamudeen A <nia@redhat.com>

After PR ceph#66244, all mgr modules run inside the same Python interpreter.
That means they also share the same logging subsystem.
Previously, each module attached its handlers to the root logger. In practice,
whichever module initialized logging last effectively “owned” the root logger,
and log messages from other modules could end up attributed incorrectly.

This change scopes logging per module. Each module now registers its handlers
on a dedicated logger named after the module itself, with propagate=False to avoid
leaking messages into the root logger.

Now, the getLogger() default (no args) returns the module's named logger
rather than the root logger. This ensures self.log routes correctly.

Fixes: https://tracker.ceph.com/issues/74848
Signed-off-by: Nitzan Mordechai <nmordec@ibm.com>

as the modules are now being loaded onto the main interpreter (see
ceph/ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543
Signed-off-by: Nizamudeen A <nia@redhat.com>

as the modules are now being loaded onto the main interpreter (see
ceph/ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543
Signed-off-by: Nizamudeen A <nia@redhat.com>

as the modules are now being loaded onto the main interpreter (see
ceph/ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543
Signed-off-by: Nizamudeen A <nia@redhat.com>

as the modules are now being loaded onto the main interpreter (see
ceph/ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543
Signed-off-by: Nizamudeen A <nia@redhat.com>

as the modules are now being loaded onto the main interpreter (see
ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543
Signed-off-by: Nizamudeen A <nia@redhat.com>
(cherry picked from commit c0f77e4)

 Conflicts:
	src/pybind/mgr/cephadm/agent.py
 - removed the log filters and kept the ssl changes as it is
	src/pybind/mgr/dashboard/module.py
 - only added the new CherryPyMgr import
	src/pybind/mgr/prometheus/module.py
 - accepted the incoming changes

as the modules are now being loaded onto the main interpreter (see
ceph/ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543
Signed-off-by: Nizamudeen A <nia@redhat.com>
(cherry picked from commit c0f77e4)

 Conflicts:
	src/pybind/mgr/cephadm/agent.py
 - removed the log filters and kept the ssl changes as it is
	src/pybind/mgr/dashboard/module.py
 - only added the new CherryPyMgr import
	src/pybind/mgr/prometheus/module.py
 - accepted the incoming changes

as the modules are now being loaded onto the main interpreter (see
ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543
Signed-off-by: Nizamudeen A <nia@redhat.com>

as the modules are now being loaded onto the main interpreter (see
ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543, https://tracker.ceph.com/issues/74980
Signed-off-by: Nizamudeen A <nia@redhat.com>

as the modules are now being loaded onto the main interpreter (see
ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543, https://tracker.ceph.com/issues/74980
Signed-off-by: Nizamudeen A <nia@redhat.com>

as the modules are now being loaded onto the main interpreter (see
ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543, https://tracker.ceph.com/issues/74980
Signed-off-by: Nizamudeen A <nia@redhat.com>
(cherry picked from commit 13bc335)

as the modules are now being loaded onto the main interpreter (see
ceph#66244), the
cherrypy is getting hit with an issue where its global state is being
affecting all the modules updating the cherrypy config simultaneously in
the same tree.

So i am adding a CherryPyMgr which manages all the independent servers
that will be created across all modules. This CherryPyMgr will create
its own server instances by utilizing cherrypy's WSGI Server and
eliminates the global state sharing. Each module or app can create their
own tree and start an adapter which will open an independent server for
that app.

- also added a method to update the config in place so CORS urls can be
  configured without restarting servers.

Fixes: https://tracker.ceph.com/issues/74643, https://tracker.ceph.com/issues/74543, https://tracker.ceph.com/issues/74980
Signed-off-by: Nizamudeen A <nia@redhat.com>