Hi, I agree that the code is confusing…
This is part of a change that was made in order to support default states for static entities. For example, in the static configuration yaml file you can add entities of types ‘switch’ and ‘br-ex’. In the past, in order to support states for these new types, you needed to add switch.yaml and br-ex.yaml under /etc/vitrage/datasources_values, which you would most likely copy&paste from another datasource. Now, we have under /etc/vitrage/datasources_values a default.yaml file that is used for all static entities. Back to the code, I believe this is the logic: · If the datasource is part of ‘types’ (as defined in vitrage.conf) and has states configuration – use it. This is the normal behavior. · If the datasource is not part of ‘types’, we understand that it was defined in a static configuration file. Use the default states configuration. I assume that it is somehow handled in the first part of the if statement (I’m not so familiar with that code) · If neither is true – it means that the datasource is “real” and not static, and was defined in vitrage.conf types. And it also means that its states configuration is missing, so the state is UNDEFINED. And to your questions: 1. the data source is not defined -> the default states should be used 2. data source defined but state config not exist -> UNDEFINED state 3. data source defined, state config exist but the state is not found. -> I believe that somewhere in the first part of the if statement you will get UNDEFINED Hope that’s more clear now. It might be a good idea to add some comments to that function… Best Regards, Ifat. From: "Yujun Zhang (ZTE)" <zhangyujun+...@gmail.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Tuesday, 9 January 2018 at 8:34 To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [vitrage] rules in vitrage_aggregated_state() Forgot to paste the link to the related code: https://git.openstack.org/cgit/openstack/vitrage/tree/vitrage/entity_graph/mappings/datasource_info_mapper.py#n61 On Tue, Jan 9, 2018 at 2:34 PM Yujun Zhang (ZTE) <zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>> wrote: Hi root causers I have been inspecting the code about aggregated state recently and have a question regarding the rules. The "not" operator in the if clause confuses me. If it is not a configured data source, how do we apply the aggregation rules? It seems this is handled in else clause. if datasource_name in self.datasources_state_confs or \ datasource_name not in self.conf.datasources.types: ... else: self.category_normalizer[vitrage_category].set_aggregated_value( new_vertex, self.UNDEFINED_DATASOURCE) self.category_normalizer[vitrage_category].set_operational_value( new_vertex, self.UNDEFINED_DATASOURCE) There are some test case describing the expected behavior. But I couldn't understand the design philosophy behind it. What is expected when 1. the data source is not defined 2. data source defined but state config not exist 3. data source defined, state config exist but the state is not found. Could somebody shed some light on it? -- Yujun Zhang -- Yujun Zhang
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
