relaxdiego
commented
4 years ago 1. There is some time (~1 min) between the ConfigMap change (read: after the juju applies the new pod spec so ConfigMap is actually changed) and the new config file being actually rendered on the filesystem. Therefore, calling `/-/reload` in the `config-changed` hook immediately does not make any sense, since new config has not arrived. Still need to think about how can we wait for the new config file or make the process faster (e.g why the config file arrives with such noticeable delay? Do we have any other option to deliver the config file to the service container?)
I wonder if it has something to do with this: https://kubernetes.io/docs/concepts/configuration/configmap/#mounted-configmaps-are-updated-automatically
If the delay is caused by some setting in the underlying k8s cluster, then we'll have take that into consideration and maybe keep polling and somehow find out that the file has finally updated before telling prometheus to reload.
2. Failing unit test:______________________________________________ OnConfigChangedHandlerTest.test__it_blocks_until_pod_is_ready ______________________________________________ self = <charm_test.OnConfigChangedHandlerTest testMethod=test__it_blocks_until_pod_is_ready> mock_stored_state_cls = <MagicMock name='StoredState' spec_set='StoredState' id='4358979408'>, mock_pod_spec = <function set_juju_pod_spec at 0x103d3b560> mock_juju_pod_spec = <function build_juju_pod_spec at 0x103d5ae60>, mock_time = <NonCallableMagicMock name='time' spec_set='module' id='4358998224'> mock_k8s_mod = <NonCallableMagicMock name='k8s' spec_set='module' id='4359109776'> mock_build_juju_unit_status_func = <function build_juju_unit_status at 0x103d5add0> @patch('charm.build_juju_unit_status', spec_set=True, autospec=True) @patch('charm.k8s', spec_set=True, autospec=True) @patch('charm.time', spec_set=True, autospec=True) @patch('charm.build_juju_pod_spec', spec_set=True, autospec=True) @patch('charm.set_juju_pod_spec', spec_set=True, autospec=True) @patch('charm.StoredState', spec_set=True, autospec=True) def test__it_blocks_until_pod_is_ready( self, mock_stored_state_cls, mock_pod_spec, mock_juju_pod_spec, mock_time, mock_k8s_mod, mock_build_juju_unit_status_func): # Setup mock_fw_adapter_cls = \ create_autospec(framework.FrameworkAdapter, spec_set=True) mock_fw_adapter = mock_fw_adapter_cls.return_value mock_juju_unit_states = [ MaintenanceStatus(str(uuid4())), MaintenanceStatus(str(uuid4())), ActiveStatus(str(uuid4())), ] mock_build_juju_unit_status_func.side_effect = mock_juju_unit_states mock_event_cls = create_autospec(EventBase, spec_set=True) mock_event = mock_event_cls.return_value mock_state = mock_stored_state_cls.return_value > mock_state.set_default(is_started=False) test/charm_test.py:113: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <NonCallableMagicMock name='StoredState()' spec_set='StoredState' id='4355493072'>, name = 'set_default' def __getattr__(self, name): if name in {'_mock_methods', '_mock_unsafe'}: raise AttributeError(name) elif self._mock_methods is not None: if name not in self._mock_methods or name in _all_magics: > raise AttributeError("Mock object has no attribute %r" % name) E AttributeError: Mock object has no attribute 'set_default' /usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest/mock.py:598: AttributeError
This is due to the fact that framework.StoredState doesn't statically define a set_default method. Rather it uses some metaprogramming to set it which @patch doesn't see so it's telling you the method doesn't exist in the mocked object. You could spec_set=False but that runs the risk of your mock's method signatures going out of sync with the methods of the real object.
exceptorr
Two comments to address (@relaxdiego - any ideas will be very welcome and appreciated!):
1) There is some time (~1 min) between the ConfigMap change (read: after the juju applies the new pod spec so ConfigMap is actually changed) and the new config file being actually rendered on the filesystem. Therefore, calling
/-/reloadin theconfig-changedhook immediately does not make any sense, since new config has not arrived. Still need to think about how can we wait for the new config file or make the process faster (e.g why the config file arrives with such noticeable delay? Do we have any other option to deliver the config file to the service container?) 2) Failing unit test: